Describe what EntityManager.detach(entity), EntityManager.clear() and closing the EntityManager each do to the lifecycle state of the entities involved, and what happens to changes made to those entities that had not been flushed yet.

## The three eviction operations They differ only in scope. **`em.detach(entity)`** removes one instance from the persistence context. Hibernate's native equivalent is `session.evict(entity)`. Everything else in the context stays managed. **`em.clear()`** removes *all* managed instances and resets the context to empty. It also throws away the queued actions that have not been flushed. **`em.close()`** releases the EntityManager entirely. The context is gone, and any further use of that EntityManager throws `IllegalStateException`. Entities you already hold references to survive as detached objects. A fourth, implicit route exists: with a transaction-scoped EntityManager (the container-managed style), everything becomes detached when the transaction ends, without any explicit call. ## Why unflushed changes vanish silently When Hibernate loads or persists an entity, it stores two things: the instance itself in an identity map, and a **snapshot** — an array of the property values as of the last synchronisation with the database. Dirty checking at flush is nothing more than comparing the live object to that snapshot and emitting an UPDATE for the differences. Eviction discards both the entry and the snapshot. There is no longer anything to compare, and no registration to iterate over at flush. So a modification made a line before `detach()` disappears without a warning, an exception, or a log line at default levels. This is one of the most-reported "my update didn't save" causes, and the fix is a discipline: **flush before you evict** if the changes matter. ``` entity.setStatus(SHIPPED); em.flush(); // UPDATE goes out now em.detach(entity); ``` ## clear() also drops queued work `clear()` is stronger than "detach everything": it also empties the action queue. Entities passed to `persist()` but not yet flushed are therefore never inserted, and pending deletes are not executed. That is intended — `clear()` means "forget this unit of work". Per-instance `detach()` is subtler and worth flagging as a trap: it removes the entity from the context, but a queued insert action for that entity may already exist in the action queue and can still fire at flush. Do not treat `detach()` as an "undo persist". If you need to abandon pending work, `clear()` (or rolling the transaction back) is the honest tool. ## What a detached instance can and cannot do After eviction the instance keeps its identifier and whatever data was already loaded. What it loses: - **Automatic write-behind**: setters produce nothing. - **Lazy loading**: uninitialised proxies and collections can no longer fetch, because the session that would fetch them is gone or no longer owns them. - **Identity guarantees**: a later `find()` for the same id in the same (or a new) context creates a *different* instance, so `==` comparisons between the detached copy and the freshly loaded one fail. Entities that will be compared across contexts need an `equals`/`hashCode` based on a stable business key rather than a generated id. What it keeps: its data, so it is perfectly good as a read-only carrier — which is why detaching deliberately is sometimes the point, not an accident. ## The flush + clear batching idiom The canonical use of `clear()` is bounding memory in a long unit of work: ``` for (int i = 0; i < rows.size(); i++) { em.persist(map(rows.get(i))); if (i % 50 == 0) { em.flush(); em.clear(); } } ``` `flush()` writes the batch, `clear()` releases the instances and their snapshots so the heap stays flat and dirty checking does not degrade as the context grows. Getting the order wrong — `clear()` before `flush()` — throws the batch away. ## Deliberate detachment as a design tool Sometimes you evict on purpose: you want to hand an object to code that must not accidentally write to the database, or you are about to mutate a loaded entity for presentation only. `em.detach(x)` makes that safe and explicit. Compare it with the alternatives — mapping to a DTO (clearer, more code) or marking the entity read-only via Hibernate's `Session.setReadOnly` (keeps it managed and lazily loadable, but skips dirty checking). Choosing between those three is a real design decision, not a matter of taste: detachment removes lazy loading, read-only keeps it. ## Quick diagnosis table - Change lost with no error → something evicted the instance before flush. - `IllegalStateException: EntityManager is closed` → you kept using the manager after `close()`. - Insert happened even though you "cancelled" it with `detach()` → queued action still in the queue; use `clear()` or rollback. - Heap climbing through a long loop → you flushed but never cleared.