NHibernate read-write cache strategy isolation level verification

Second-level cache read-write strategy isolation requirement

The read-write concurrency strategy for NHibernate's second-level cache expects the database transaction isolation level to be at least repeatable read. This ensures that soft locks used by the cache correctly prevent stale reads when concurrent transactions modify cached entities.

Configuration gap

NHibernate provides the hibernate.connection.isolation property (accepting ADO.NET IsolationLevel integer values such as 4096 for RepeatableRead) but does not validate that the active database connection actually honors this setting. Some ADO.NET providers or connection pools ignore the property, and the default isolation level for SQL Server, PostgreSQL, and Oracle is read committed.

Verification challenge

There is no built-in startup check or runtime assertion that confirms the effective isolation level matches the cache strategy's requirement. A mismatch can silently return stale entities from the cache after a concurrent commit, without throwing an exception or logging a warning.

What is the reliable way to confirm that the configured isolation level is actually enforced by the provider and connection pool at runtime? How can an application detect a mismatch between the declared hibernate.connection.isolation value and the database session's effective isolation level? Should a custom validator be added to the NHibernate integration test suite to fail fast when the isolation level is insufficient for the chosen cache strategy?