Object States

Hibernate entities move through four lifecycle states during their existence:

1. Transient The object exists in memory but has no association with a Hibernate Session and no row in the database. Created with new; Hibernate is completely unaware of it. No identifier is assigned by the ORM.

2. Persistent (Managed) The object is associated with an open Session (persistence context) and has a corresponding database row. Hibernate tracks all field changes via dirty checking and flushes them as SQL at transaction commit or explicit flush. This state is entered via persist(), find(), merge(), or any query result.

3. Detached The Session has been closed (or the object was explicitly detached with evict() / detach()). The entity still holds a valid database ID, but changes are no longer tracked. To persist changes, the object must be re-associated with a new Session using merge(), which returns a new managed instance.

4. Removed remove() has been called on a persistent entity. Hibernate schedules a DELETE for the next flush. The object should not be used after this call.

Transition diagram:

Transient ──persist()──► Persistent ──remove()──► Removed
                │                │
           session.close()    evict()/detach()
                │                │
                └──────────► Detached
                                 │
                             merge() ──► Persistent (new managed copy)

> Common interview point: merge() does not make the passed-in detached object persistent — it returns a new persistent instance with the detached object's state copied into it.

When a Hibernate object is in the Transient state, it has been created with the new keyword but has not yet been associated with a Hibernate Session (persistence context). Key characteristics:

• No database row: there is no corresponding record in the database.
• No assigned ORM identifier: Hibernate has not generated or assigned a primary key (unless the developer set one manually).
• Not tracked: Hibernate is completely unaware of the object. No dirty checking, no change synchronization.
• Garbage collectible: if no Java reference points to it, the object is eligible for GC with no database impact.

Transitioning out of Transient:

Call session.persist(entity) (or em.persist(entity)) to make the object Persistent. At the next flush (or immediately for some ID generation strategies like IDENTITY), Hibernate inserts the row:

Product product = new Product();          // Transient
product.setName("Widget");
product.setPrice(new BigDecimal("9.99"));

em.persist(product);                      // Now Persistent
// At transaction commit: INSERT INTO product (...) VALUES (...)

> Gotcha: calling merge() on a transient object (one with no ID) will insert it, similar to persist(), but returns a new managed instance rather than managing the original object in-place.

An entity in the Persistent (also called Managed) state is attached to an open Hibernate Session (or JPA EntityManager) and has a corresponding row in the database.

Key characteristics:

1. Automatic dirty checking: Hibernate takes a snapshot of the entity's state when it enters the persistence context. At flush time it compares the current state to the snapshot and automatically issues UPDATE SQL for any changed fields — no manual update() call is needed.

@Transactional
public void updateEmail(Long userId, String newEmail) {
    User user = em.find(User.class, userId);  // loaded as Persistent
    user.setEmail(newEmail);                  // just a setter
    // Hibernate generates: UPDATE user SET email = ? WHERE id = ?
}

1. First-level cache: within the same Session, loading the same entity by ID twice returns the same Java object — no second database query.

2. Identity guarantee: within a Session, only one Java instance can represent a given database row. This prevents aliasing bugs.

3. Cascading: operations on the persistent entity can cascade to associated entities based on cascade settings on the relationship annotations.

Exiting Persistent state:

• Session closes → entity becomes Detached.
• em.remove(entity) → entity becomes Removed.
• em.detach(entity) → entity becomes Detached immediately.

An entity in the Detached state was previously Persistent (associated with an open Session) but is no longer attached to any active persistence context.

How an entity becomes Detached:

• The Session / EntityManager that managed it was closed.
• em.detach(entity) or session.evict(entity) was called explicitly.
• em.clear() was called, detaching all entities in the context.

Key characteristics:

• The entity still has a valid primary key and represents a database row.
• Changes are NOT tracked: modifying fields on a detached entity has no database effect — Hibernate does not know about it.
• The entity can be passed across layers (e.g., from service to controller, or serialized over a network) without holding a database connection open.

Re-attaching a Detached entity:

Use merge() to create a new Persistent copy with the detached object's current state:

// detachedProduct was loaded in a previous transaction
detachedProduct.setPrice(new BigDecimal("19.99"));  // change not tracked yet

@Transactional
public Product save(Product detachedProduct) {
    return em.merge(detachedProduct);  // returns a new Persistent instance
    // UPDATE is issued at commit
}

> Gotcha: accessing a lazy-loaded collection on a detached entity throws LazyInitializationException because there is no open Session to execute the SQL. Use @EntityGraph, JOIN FETCH, or @Transactional to ensure collections are loaded while still attached.

Hibernate manages entity state transitions automatically through the persistence context (Session / EntityManager) and the current transaction. The developer triggers transitions by calling specific API methods; Hibernate handles all the database synchronization.

Transition mechanisms:

Dirty checking (auto-synchronization):

When a Persistent entity's fields change, Hibernate detects this at flush time by comparing the current state to the snapshot taken at load time. Changed fields are written with an UPDATE statement — no explicit save call is needed.

Flush timing:

By default (FlushMode.AUTO), Hibernate flushes:

• Before executing a query (to ensure queries see the latest in-memory changes).
• At transaction commit.

Cascade types (CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REMOVE, CascadeType.ALL) propagate state transitions from a parent entity to its associated child entities automatically.

> Interview gotcha: calling merge() on a detached entity does NOT make the original object persistent. It copies the state into a new (or existing) managed instance and returns that. The detached object remains detached.

Both methods are used to save data, but they operate on different entity states and have important behavioral differences.

persist(entity)

• Transitions a Transient entity to the Persistent (Managed) state.
• The entity must not already have a manually assigned ID that exists in the database (for @GeneratedValue IDs this is not an issue).
• The INSERT is typically deferred until flush time.
• Returns void; the passed instance itself becomes managed.

merge(entity)

• Works with Detached entities (entities that were previously managed but the session/entity manager was closed).
• Copies the state of the detached entity into a new managed instance (or an existing managed instance if one with the same ID is already in the persistence context).
• Returns a new managed instance — the original detached object is NOT managed after the call.
• If no row exists with that ID, an INSERT is performed; if one does exist, an UPDATE is performed.

Critical interview gotcha:

// WRONG — common mistake
Order detached = getDetachedOrder();
em.merge(detached);
detached.setStatus("CANCELLED"); // has NO effect — detached is still detached!

// CORRECT
Order managed = em.merge(detached);
managed.setStatus("CANCELLED"); // this will be flushed

Summary table: