Hibernate second-level cache concurrency strategy after moving from 5.x to 6.x: which setting preserves correctness?

Answer to the Core Question

When migrating from Hibernate 5.x to 6.x, the READ_WRITE concurrency strategy is the only one that guarantees the same level of data freshness for entities updated by multiple threads. NONSTRICT_READ_WRITE remains a stale‑read risk, and TRANSACTIONAL only works with a JTA‑aware provider such as Infinispan in transactional mode.

1. NONSTRICT_READ_WRITE vs. READ_WRITE

• READ_WRITE uses a soft‑lock mechanism: when a transaction updates an entity, the cache entry is locked until commit, preventing other sessions from reading stale data.
• NONSTRICT_READ_WRITE does not lock; it merely invalidates the cache entry after commit, so a concurrent read may still see the old value until the invalidation propagates.
• Both 5.x and 6.x document this behavior identically; the migration does not change the contract.

2. TRANSACTIONAL with Plain EhCache

• In 6.x the TRANSACTIONAL strategy is meaningful only when the cache provider implements JTA transactions (e.g., Infinispan configured for transactional mode).
• When configured with a non‑transactional provider such as plain EhCache (via JCache), Hibernate will either reject the strategy or silently downgrade it to READ_WRITE behavior, depending on the region factory implementation.
• Therefore, unless you are using a JTA‑aware provider, do not rely on TRANSACTIONAL for correctness.

3. Duplicate Region Names

• Sharing a region name across multiple entities or collections is a real hazard in 6.x; entries can evict or poison each other, producing confusing misses or stale data that invalidates correctness testing.
• Give each entity (and collection) a distinct region name or use the default naming convention that appends the entity/collection name to the region prefix.

4. How to Verify Per‑Region Behavior in Tests

1. Enable statistics: hibernate.generate_statistics=true.
2. Explicitly enable the second‑level cache in the test configuration.
3. Run a simple read‑write sequence in two threads:
   • Thread A updates an entity and commits.
   • Thread B reads the same entity immediately after.
   • Assert that the value read by B matches the committed value when the strategy is READ_WRITE.
   • Repeat with NONSTRICT_READ_WRITE and observe a possible stale read.
4. Check the statistics for the region: stats.getCacheHits(), getCacheMisses(), getCachePuts().
5. List the configured region names at startup (SessionFactory.getCache().getCacheRegions()) to confirm uniqueness.

5. Practical Recommendation

For correctness in a concurrent environment, switch all frequently updated entities to READ_WRITE and remove any NONSTRICT_READ_WRITE declarations unless you accept brief staleness. If you need true transactional guarantees, migrate to a JTA‑aware provider and keep TRANSACTIONAL. Finally, audit region names to avoid accidental sharing.

Missing Diagnostic Detail

To fine‑tune the recommendation for your specific environment, could you confirm which cache provider and version (EhCache 3.x, Infinispan 13.x, etc.) you plan to use in the 6.x deployment? This will help determine whether TRANSACTIONAL can be safely enabled.