> > > --> 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.)
Haaa all is clear now ;) I am planning to use hibernate is a kinda very large CMS portal and i intend to rely on the cache as much as i can ( a la Jive, using only iterator no bulk loading to maximise the cache use) hence my interest and need to fully understand how the cache is handled internally. I am a bit scared by all the synchronized method, even the "read" one is synchronized.... Are we absolutly sure we need to synchronize the read method ? the CachedItem contains pretty simple value that basically have 2 states ( the timestamp is either -1 or a value (set/unset), the cached value is either null or a value ( staled / fresh )). I tried to find an example where a read/write conflict ( either the read thread is pre empted and the write start or vis-versa) could lead to a bad cache state and i could not find one. > > 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. Ya you right, it's the same. > > 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). IMHO, Type 2 should really not be named "read-write" because we end referencing it by a read-write cache where it's instead a read only cache for read-write objects. A read-write cache is the type 3. For example, pretty much every JDO implementation got a factory wide cache (type 2, same purpose as the hibernate one) and they all call it "read only cache" because the cache is read only, we never update an object in it. > > I'm not convinced that what you are implementing is different to Type 2 > (except that it seems to have some holes...) You are right, once the holes are fixed, i end with the same thing as you. Thanks for your help Gavin, i really appreciate. Kind regards Christian Meunier ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
