Limits of NHibernate Second-Level Cache Concurrency Strategies for Mutable Data

The goal is to select a second‑level cache concurrency strategy for mutable entities that provides acceptable consistency while maximizing concurrent reads and writes in NHibernate. The documented strategies—read‑only, nonstrict‑read‑write, read‑write, and transactional—offer different locking and expiration guarantees, but the framework leaves the choice between read‑write and nonstrict‑read‑write to the developer without prescribing a rule.

Constraints include the risk of serving stale data when cache expiration is not aligned with transaction boundaries, and the fact that underlying cache providers (e.g., Redis, SysCache) may implement sliding or absolute expiration differently, affecting the observable behavior of each strategy. These uncertainties raise the following questions: What workload characteristics indicate a preference for read‑write over nonstrict‑read‑write? How should cache expiration policies be tuned to reduce stale‑data windows for each strategy? Are there provider‑specific features that make one strategy more suitable than the other?