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

Second-level cache behavior across the 5.x to 6.x boundary

I am planning a migration of an application from Hibernate 5.x to 6.x and need to settle one unresolved decision before touching configuration: the second-level cache concurrency strategy for entities that are read frequently but updated by multiple threads.

The L2 cache is configured per SessionFactory with a pluggable provider (EhCache or Infinispan in our case), and each entity declares a strategy such as READ_ONLY, NONSTRICT_READ_WRITE, READ_WRITE, or TRANSACTIONAL. I understand 6.x changed eviction semantics around cacheable entities, and I am unsure whether the strategy choices that were safe under 5.x still guarantee the same freshness guarantees under 6.x, particularly for NONSTRICT_READ_WRITE where stale reads across threads were already a documented risk.

A second constraint: our cache region names are shared across several entities today, and I have seen claims that duplicate region names within one SessionFactory can cause silent cache misses, which would make any correctness testing misleading.

Specific questions

• Does Hibernate 6.x change the effective guarantees of NONSTRICT_READ_WRITE versus READ_WRITE compared with 5.x, or is the documented semantics identical?
• Is TRANSACTIONAL still only meaningful with a JTA-capable provider in 6.x, and what happens if it is declared with plain EhCache?
• What is the recommended way to verify per-region behavior in a test, given that a disabled cache still generates cacheable queries?