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

Konrad Garus picture Konrad Garus · Feb 22, 2011 · Viewed 7.7k times · Source

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

Piotr Kochański picture Piotr Kochański · May 16, 2011

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