Clustered hibernate cache with ehcache: nonstrict vs. strict read write

Question

What is the real difference between nonstrict-read-write and read-write? I can read ehcache and Hibernate docs, but as far as I can see they only say that "read-write is better if you do updates". I find it unsatisfactory.

I may have an issue with long-lived cached collection configured like this:

<cache name="trx.domain.Parent.children" maxElementsInMemory="5000"
    eternal="false" overflowToDisk="false" timeToIdleSeconds="1200"
    timeToLiveSeconds="1800">
    <cacheEventListenerFactory
        class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
        properties="replicateAsynchronously=true, replicatePuts=true, replicateUpdates=true, replicateUpdatesViaCopy=false, replicateRemovals=true" />

<set name="children" lazy="false" inverse="true">
    <cache usage="nonstrict-read-write"/>
    <key column="callout_id" />
    <one-to-many class="Child" />
</set>

What exactly happens when the collection is updated, on the node where the update occurs and others? What is the difference between nonstrict-read-write and read-write here? Is it possible that a node will use its stale 10-minute version from cache?

Note the lengthy timeouts and asynchronous replication.

Answer 1

Read-write: if two transactions tries to modify data, then these transactions are isolated at the "read committed" level (or repeatable read, if database is set to that) - usually that's enough, typically we don't need "serializable" isolation level.

Nonstrict read-write: cache is not locked at all, so if two transactions modify data we never know what we get, we don't have guarantee that cache state = database state.

This is safe only if it is very unlikely that data would be modified simultaneously by two transactions. We need to set appropriate cache timeout too.

For more details and a very good explanation look here: hibernate cache strategy

Answer 2

NONSTRICT_READ_WRITE: Cache is updated after a transaction that changed the affected data has been committed. Thus, strong consistency is not guaranteed and there is a small time window in which stale data may be obtained from cache. This kind of strategy is suitable for use cases that can tolerate eventual consistency.

READ_WRITE: This strategy guarantees strong consistency which it achieves by using ‘soft’ locks: When a cached entity is updated, a soft lock is stored in the cache for that entity as well, which is released after the transaction is committed. All concurrent transactions that access soft-locked entries will fetch the corresponding data directly from database.