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

Goal

Determine the best second‑level cache strategy to minimize stale reads when domain objects are updated concurrently.

Constraints

Grails maps domain classes to Hibernate entities. The cache configuration is declared in the domain class’s static mapping block, e.g. cache usage: 'read-write' or cache usage: 'nonstrict-read-write'. The choice affects soft‑lock overhead, write‑side latency, and the likelihood of readers seeing outdated data.

Unresolved Decision

Should the application use read-write caching, which enforces soft locks on updates, or nonstrict-read-write, which foregoes locking and accepts occasional stale reads?

Specific Questions

• When a domain instance is updated in one transaction, how quickly can a reader in a separate transaction see the new value under read-write caching?
• What is the performance impact of soft‑lock contention in read-write compared to the lock‑free nonstrict-read-write strategy when write traffic is high?
• How does enabling query caching (e.g., cacheable: true) interact with entity cache invalidation for each strategy, and can it exacerbate stale‑data visibility?