I meant to reply to this email a looong time ago, but never found a chance. So, for the record:
I've been looking at the ReadWriteCache and NonStrictReadWrite cache implementations. I find them to be a little unsatisfying in the way that they lock objects out of the cache during transactions. For example, NonStrictReadWriteCache times out locks after 10 seconds, which definitely comes across as impure.
No, it releases locks in after transaction completion. There is also a timeout, to account for the possibility of the thread dying without
releasing its lock. (Perhaps the timeout is too short.)
Certainly, if a thread is in a transaction that has updated an object, then it should not store the change in the cache as those changes are not visible outside of the transaction yet. However, all other threads should be able to continue to cache the object outside of the transaction as normal.
Of course, they are allowed to cache to the session cache. Hibernate has two layers of cache. The concurrency strategies are only used for the second-level (shared) cache.
I propose the following algorithm, which I am planning to implement:
- Threads that are not involved in a transaction read and write from the cache as normal.
Everything is a transaction, as far as we are concerned.
- When a thread is in a transaction and it updates an object, it passes to the CacheConcurrencyStrategy its Transaction object as well as the object to be cached. The CacheConcurrencyStrategy places this object in a special sub-cache that is associated with the transaction.
- When a thread that is in a transaction attempts to get an object from the cache, the CacheConcurrencyStrategy first checks to see if the object is in the sub-cache associated with the transaction. If it finds it, then that object is returned. Otherwise, the CacheConcurrencyStrategy searches the main cache as normal.
That is what the session-level cache does.
- Once a transaction is commited, the CacheConcurrencyStrategy is notified. The sub-cache associated with the transaction is flushed, but not before each object that is stored in the sub-cache is flushed from the main cache (if present in the main cache).
- If a transaction is rolled back, then the CacheConcurrencyStrategy simply flushes the sub-cache associated with the transaction with no further action.
Timeouts are not required as the sub-cache will still be subject to the normal rules of the Cache algorithm. For example, consider an LRU caching algorithm. If a transaction crashes and does not commit or rollback, then the objects stored in the sub-cache associated with that transaction will never be accessed again and will eventually become the least recently used.
Also note that this CacheConcurrencyStrategy will be correct when used in conjunction with a clustered cache, such as SwarmCache.
Any comments or suggestions are appreciated.
Probably you figured out all this for yourself by now, John .... sorry for not replying at the time. My Bad.
Gavin
-- Gavin King JBoss Group +61 410534454 http://hibernate.org
------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
