> --> 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
