Choosing Between read-write and nonstrict-read-write Caching for Grails Domain Classes

Direct recommendation

If your workload has high write contention on a few hot entities and you can tolerate a few milliseconds of stale reads, choose nonstrict-read-write. If you need guaranteed visibility of committed updates for every reader and write contention is moderate, choose read-write.

Confirmed behavior

Visibility after update (read-write)

When a transaction updates an entity, Hibernate places a soft‑lock token in the second‑level cache for that key. Readers in other transactions block on that lock until the updating transaction commits. After commit the lock is released and the refreshed value is visible. The latency equals lock hold time plus cache propagation (typically a few milliseconds on a single node).

Visibility after update (nonstrict-read-write)

Updates evict or invalidate the cache entry asynchronously without locking. A reader that already holds a cached copy or races the invalidation can return stale data until the next cache miss forces a database reload. The stale‑read window depends on the cache provider’s invalidation latency (often milliseconds in clustered caches, but can be longer under replication lag).

Soft‑lock contention under high write traffic

read-write serializes access to hot keys because each update acquires the soft lock. This adds write‑side latency and reduces throughput proportionally to contention intensity. nonstrict-read-write avoids locking entirely, so write throughput scales better, at the cost of occasional stale reads.

Query cache interaction

Enabling cacheable: true stores result‑set identifiers in the query cache. If the entity cache is invalidated but the query cache retains stale identifiers, subsequent query executions may return identifiers for entities that are no longer current, worsening stale‑data visibility for both strategies. Query cache regions must be evicted in sync with entity cache regions.

Likely explanation (provider‑dependent)

• Soft‑lock implementation varies: some providers use a special marker entry, others use separate lock strips. Contention metrics differ widely.
• In clustered caches (Infinispan, Hazelcast, Ehcache clustered) replication is asynchronous; nonstrict-read-write stale‑read probability rises with replication lag, while read-write locks are usually local to the node acquiring them, so cross‑node readers may still see brief staleness until invalidation arrives.
• Hibernate 6 changed the internal cache SPI; not all providers have fully aligned soft‑lock semantics.

Verification steps for your environment

1. Enable Hibernate statistics: hibernate.generate_statistics=true and monitor second_level_cache_put_count, second_level_cache_hit_count, second_level_cache_miss_count, and any lock‑contention metrics under realistic load.
2. Run a controlled concurrency test: one thread updates a domain instance in a loop, another reads it; measure stale‑read frequency for each strategy with your cache provider.
3. Check your cache provider documentation for soft‑lock details and invalidation latency guarantees (e.g., Infinispan lock acquisition timeout, Ehcache replicateUpdatesViaCopy).
4. Verify query cache region configuration: ensure hibernate.cache.use_query_cache=true and that eviction/expiration policies match the entity cache policies.
5. Review Grails/Hibernate release notes for cache‑strategy changes (especially Hibernate 5.4 → 6.0 migration).

One missing diagnostic detail

What cache provider and cluster topology (standalone, replicated, distributed) are you using? The answer changes the recommendation because soft‑lock scope and invalidation latency differ markedly between providers.