Re: [Hibernate] JCS cache - Distributable read-write

[Brad C. <bra...@wo...>]

we currently use an application-level cache in our cms application that
operates like this:

1.  if i am getting a "transient" (r/o) object - go look in the cache, if
not there, load/find it with hibernate and place it in the cache.
2. if i want a "persistent" object (i want to modify it) - load/find it with
hibernate, modify, commit and then remove the object from the cache.

i am expecting that this will work in a clustered environment as long as all
the caches r notified to remove an object (if they have a copy) when it is
modified.

to add something like this to hibernate would require API changes that
enable the application to specify whether a persistent or transient instance
is required from a load/find.  i have a vague recollection that anton may
have brought this "r/o load/find" concept up before - is there a
(performance) benefit to be gained from this (with or w/o this caching
idea)?

brad

----- Original Message -----
From: "Gavin King" <ga...@ap...>
To: "Christian Meunier" <vc...@cl...>
Cc: "hibernate list" <hib...@li...>
Sent: Saturday, September 21, 2002 1:12 AM
Subject: Re: [Hibernate] JCS cache - Distributable read-write


>
> > --> The session hold a set of the items that have been updated/deleted
in
> the transaction,
> > when the transaction commit, we iterate the set and remove each entry
from
> the cache.
>
> but merely removing is not enough, because after removal, another
> transaction (that started *earlier*) could come along and try to write
stale
> data in the cache because the database is actually free to return stale
data
> to a read operation. Thats the reason for the more complicated logic in
> read-write cache. What you have to ensure is that a transaction that
writes
> to the cache _started after the completion_ of the transaction that
removed
> the object from the cache. (This is what the current read-write cache
does.)
>
> > With this logic, we end with a read only cache ( we never update an item
> in the cache) for
> > mutable objects.
>
> I don't understand how this is different to the existing read-write cache
> which actually doesn't allow *update* of a cached item, it only allows
> removal from the cache when an object is updated.
>
> There seems to be three types of cache:
>
> Type 1:
> you can add an item
> you can't remove an item
> you can't update an item
>
> Type 2:
> you can add an item
> you can remove an item (when you attempt to update it on the DB)
> you can't update an item
>
> Type 3:
> you can add an item
> you can update an item (when you *know* you have updated its persistent
> state)
>
> Hibernate supports Type 1 (read-only) and Type 2 (read-write) but not Type
> 3. Type 3 would require Hibernate to know whether or not a transaction is
> successful (which it doesn't, in general).
>
> I'm not convinced that what you are implementing is different to Type 2
> (except that it seems to have some holes...)
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>