We are using a custom clustered second-level cache similar to SwarmCache in the sense that removes performed on the local cache are distributed to all other caches in the cluster (clustered invalidation). My understanding of the documentation is that NonstrictReadWriteCache is the correct CacheConcurrencyStrategy to use with this type of cache. However, we observed that loading an object with LockMode.READ set (to intentionally bypass the cache) was resulting in the generation of invalidation messages in the cluster. A look at the Hibernate code revealed that DefaultLoadEventListener.lockAndLoad calls lock/release on the CacheConcurrencyStrategy, and NonstrictReadWriteCache.release calls remove on the underlying cache, generating the invalidation. The call from DefaultLoadEventListener.lockAndLoad to NonstrictReadWriteCache.release appears to be contrary to the javadoc for CacheConcurrencyStrategy.release which states that it is "Called when we have finished the attempted update/delete (which may or may not have been successful), after transaction completion."

My questions are:
- Is it correct that lockAndLoad is calling release? If it is (as I suspect) correct, perhaps the Javadoc for CacheConcurrencyStrategy needs updating?
- More importantly, why is it necessary that NonstrictReadWriteCache.release calls remove on the underlying cache? As far as I can tell, lock/release on a nonstrict cache should be a no-op. Even the Javadoc for NonstrictReadWriteCache.release says the purpose is to "Invalidate the item (again, for safety)." Is there some problem that might be caused by not calling remove, i.e. is it intentional that loads with LockMode.READ should generate invalidations in the cluster?

We are using Hibernate version 3.1.2.