Wanted to pick up this old thread and add a few observations I've made: EHCache and similar are working on an entirely different code path ... the CacheConcurrencyStrategy is ReadWriteCache rather than TransactionalCache; ReadWriteCache is a pretty complex scheme, but the basic idea of it is that it stores lock objects in the cache that wrap the actual cached objects and keeps lock state and timestamps in the lock objects. AFAIK the two TreeCache based caches are the only users of TransactionalCache. Yes, the fail-fast variant of put is used currently. Issues that I'm aware of with it: - It doesn't work with optimistic locking (just broken? doesn't make senes? not sure) - It doesn't replicate quite properly (the "fail-silently" option isn't replicated) - It isn't handled for INVALIDATE_SYNC at all right (The 0-timeout isn't propagate) - It's not 100% correct To expand on the last, the problem is that you can have: a) get() returns null b) new data or delete comimtted in database and cache c) put() overwrites the newer data I'd argue that get() needs to establish a hard read lock (even when the node isn't there, even if the isolation mode is READ_COMMITTED) that is upgraded to a write lock on put() and then released/downgraded afterwards. (Doing the get()/put() pair in their own transaction might make sense, just as the fail-fast put is done in its own transaction now) This would likely require some Hibernate <=> cache changes to make sure that a failed get() is always followed by another call (a put() on success, but the item might not have been in the database, or there could have been other failures.) The above is of course somewhat similar to what the cache loader infrastructure does, but wedging into that would be more invasive on the Hibernate side. Anyways, I don't want to go into a lot more detail here, but just wanted to point out that dealing only with the put() and not considering the get()/put() cycle has some issues. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972304#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...