Persistence Context & Session

The persistence context holds a strong reference to every entity it loads, plus a snapshot copy of its loaded values for dirty checking — roughly double per entity, never released until evict, clear or close. Fix it with periodic flush()+clear(), read-only or stateless access, and paged or scrolled reads.

Children are merged only where the association declares CascadeType.MERGE or ALL; otherwise new children fail at flush as transient references. With orphanRemoval, any child missing from the incoming collection is deleted — so a partially populated collection silently destroys rows.

openSession() always creates a new session that you must close yourself. getCurrentSession() returns the session bound to the current context — thread or JTA transaction, per hibernate.current_session_context_class — creating it on first call and closing it automatically at transaction end.

Callbacks are simple but blind to old values, bulk JPQL, native SQL and outside writers. Envers versions entities automatically with revision metadata and a query API, but still only sees ORM writes and grows tables. Triggers catch every write including out-of-band ones, but lose application context and are database-specific.

Move to transaction-per-request-handler: the service fetches exactly what the response needs and returns immutable projections, so nothing lazy survives into rendering. Migrate endpoint by endpoint behind statement-count tests, then disable the request-scoped session last.

Go native when JPA has no equivalent and the workaround is worse: StatelessSession bulk work, multiLoad, natural-id lookup, @Filter, custom types, Hibernate lock modes, statistics. Contain it behind narrow, documented seams rather than scattering unwrap() calls.

Enhancement instruments entity classes so each field write records the attribute name in a tracker on the object. At flush Hibernate asks the entity which attributes are dirty instead of walking snapshots, making flush proportional to what changed rather than what was loaded. Worth it only for large persistence contexts or wide entities; mutating a value object in place can go undetected.

It returns true only when that exact instance is managed by the current persistence context. It is reference-based, not id-based, so a detached copy carrying the same id returns false even while a different managed instance of the same row is tracked.

Usually nothing: no transaction commits afterwards, so the change is discarded silently when the session closes. If automatic flushing is left enabled, a query during rendering can auto-flush it — writing outside any transaction, in auto-commit, with no rollback possible.

All three are ways to hold an application-level transaction across user think-time. Detached graphs are cheap but stale and destructive on merge; an extended persistence context keeps identity and dirty checking at the cost of server memory and pinned state; a change set re-read each step is the most robust. Whichever you pick, carry a version token and surface conflicts to the user rather than silently resolving them.