Walk through what Hibernate's READ_WRITE second-level cache strategy does to a cached entry while a transaction updates that row — what a soft lock is, what concurrent readers see — and how NONSTRICT_READ_WRITE differs.

## The problem READ_WRITE solves A second-level cache provider is usually not transactional. It has no idea whether your database transaction will commit or roll back, and it can be read by other threads at any instant. So if Hibernate naively wrote the new entity state into the cache at flush time, two things break: a rollback would leave the cache holding a value that never existed in the database (a dirty read served to everyone), and interleaved writers could install values out of order. READ_WRITE exists to get approximately **read-committed** behaviour out of a non-transactional cache. ## The soft lock A *soft lock* is just a special marker object stored in the cache region under the entity's key, in place of the cached state. It is "soft" because it is advisory and lives only in the cache — it locks nothing in the database and does not block any thread. Its meaning is: *a write against this key is in progress, so do not trust anything here.* While a soft lock occupies the key: - Readers that consult the region get the marker instead of usable state and treat it as a **cache miss**, falling through to a database SELECT. Correct, just slower. - Attempts to put a value (for example, another session finishing a load) are rejected, so a concurrent reader cannot overwrite the lock with the value it read. - A second writer locking the same key produces a *concurrent* lock; that fact is remembered, and it will prevent either writer from installing state afterwards. ## The sequence for an update 1. Hibernate dirty-checks the entity and prepares the UPDATE. 2. Before or during flush, the cache access strategy **locks** the item: the entry is swapped for the soft lock and a lock timeout is stamped on it. 3. The UPDATE goes to the database inside your transaction. 4. The transaction commits or rolls back. 5. Hibernate calls the after-completion callback. On a successful commit the strategy attempts to replace the lock with the new state — but only if the entry is still *replaceable*: no other concurrent lock intervened, and the incoming state is not older than what is there, decided by comparing the entity's `@Version` value when it has one, or by cache-entry timestamps when it does not. If any check fails, or the transaction rolled back, the strategy simply **unlocks** the entry and leaves the key empty, so the next read reloads from the database. Step 5 is the interesting one for interviews: READ_WRITE prefers to leave a hole rather than risk installing wrong data. The worst case is an extra database read, never a wrong cached value from a rolled-back transaction. Note that a versioned entity gets a more precise decision than a versionless one — another practical reason to keep a version column on cached mutable entities. ## Lock expiry If a JVM dies between step 2 and step 5, the soft lock would otherwise sit in the region forever and turn every read into a database hit. So locks are stamped with an expiry (an internal timeout, on the order of a minute in Hibernate's implementation) after which they are considered stale and the key can be repopulated normally. ## Where the cost lands Every write becomes: put lock → database write → put state or remove lock. Every read racing that write becomes a database read. Under a heavy write rate on the same keys, you pay all the cache overhead and get few hits — the region degrades into pure cost, and the honest answer is to stop caching that entity. READ_WRITE pays off for entities that are read far more often than written. ## NONSTRICT_READ_WRITE by contrast NONSTRICT does no locking. On update it **removes** the entry rather than putting the new state — at flush and again after transaction completion — so subsequent readers repopulate from the database. The double removal narrows but does not close the race: a reader that read the row *before* your commit can complete its put *after* your removal, leaving a pre-commit value cached until something evicts it. Hibernate's documentation is explicit that this strategy gives no guarantee that the cached item is the latest version, and recommends setting an expiry so any stale entry is short-lived. So the choice between the two is not "safe versus unsafe" in the abstract; it is: how bad is a few seconds of staleness for this entity, and how much per-write cache traffic do you want to pay to avoid it? Rarely-changed configuration or catalogue data survives NONSTRICT happily. Anything a user will immediately re-read and notice — balances, statuses, counters — wants READ_WRITE, or wants to be left out of the second-level cache entirely.