What production failure modes commonly show up when a Unit of Work (such as an ORM session or persistence context) is kept alive across a broader scope than a single logical operation - for example, across an entire HTTP session instead of a single request?

## Why scope matters Scoping a Unit of Work correctly — typically to one request, one message handled, or one well-defined business transaction — is arguably as important as the pattern's core mechanics, and getting the scope wrong is one of the most common real-world sources of bugs in ORM-backed systems. The mechanism behind the problem is straightforward: every entity a Unit of Work loads goes into its **identity map** and gets a retained **snapshot** for dirty checking, and neither is released until the Unit of Work itself is cleared or closed. If the Unit of Work's lifetime is tied to something long-lived — an HTTP session that persists across many requests from the same user, a singleton service, or a batch job that never opens a fresh session per chunk — then every entity ever touched across that entire lifetime stays resident in memory simultaneously, whether or not the application logic still cares about it. This produces three distinct, recognizable failure patterns: 1. **memory growth** 2. **stale reads** 3. **unintended writes** ## Memory growth The first is memory growth: identity-map and snapshot memory scales with the total number of distinct rows ever loaded across the Unit of Work's lifetime, not with how many are 'currently relevant,' so a long enough session in a busy application eventually exhausts heap — the classic incident report reads something like 'Hibernate session grew to millions of entities and the process OOM'd,' almost always traced back to a session scope accidentally broader than one request or one batch chunk. ## Stale reads The second is stale reads. The identity map's entire purpose is returning the same cached in-memory object for a given identity rather than re-querying the database — which is exactly what makes it fast and what guarantees dirty-checking correctness within a session — but it also means that if some other process updates that same row in the database, a long-lived Unit of Work has no way of knowing and will keep returning its stale cached copy indefinitely unless the application explicitly calls a refresh or evict operation on that specific entity. In a properly-scoped per-request Unit of Work this rarely matters, because the session is gone before staleness has a chance to accumulate; in a session-scoped one, it becomes a real correctness bug that shows up as 'the UI shows old data even after a successful update elsewhere.' ## Unintended writes The third, and often the most confusing to debug, is unintended writes. Because dirty checking flushes any tracked entity with changed fields at the next commit regardless of which logical operation caused the mutation, a bug where some code path mutates an entity's field but doesn't intend for that specific change to be persisted yet can sit invisibly dirty in a long-lived session and get flushed to the database by a completely unrelated commit much later, triggered by different code entirely. The resulting bug report — 'a field changed in the database but nobody can find the code that changed it' — is genuinely difficult to trace, because the actual mutation and the actual flush that persisted it happened in unrelated requests separated in time, and neither one, viewed alone, looks wrong. ## The trade-off, and the safer default The trade-off that leads teams into this trap is usually performance-motivated: reusing a session across multiple operations for the same user avoids repeatedly re-querying data the user is likely to touch again soon. In practice the safer default nearly universally recommended by ORM documentation (Hibernate's included) is **session-per-request** (or session-per-business-transaction for background work): 1. open a fresh Unit of Work at the start of each logical operation; 2. close it at the end; 3. let any genuine caching need be handled by an explicit, separately-scoped second-level cache rather than by stretching the Unit of Work itself. ## Where it shows up A concrete real-world pattern is the 'Open Session in View' anti-pattern debate in the Spring/Hibernate ecosystem: some frameworks default to keeping the Hibernate session open for the entire duration of rendering an HTTP response, originally to let lazy-loaded associations resolve conveniently in the view layer without extra round-trips, but now widely discouraged specifically because it stretches session lifetime beyond the service-layer transaction boundary and invites exactly the accumulation, staleness, and accidental-flush problems described above; Spring Boot has since made it emit a startup warning by default precisely because of these production incidents.