Core Methods

Both methods retrieve a persistent entity by its primary key, but they differ in when the database is hit and how they handle missing records — a classic Hibernate interview distinction.

get() / find() — immediate load

Hits the database immediately and returns the fully initialized entity, or null if no row exists:

// Hibernate Session API
User user = session.get(User.class, 42L);
if (user == null) {
    // handle not found
}

// JPA EntityManager equivalent (preferred in modern code)
User user = em.find(User.class, 42L);

load() / getReference() — proxy / lazy load

Returns a proxy object without hitting the database. The SQL is issued only when a non-identifier property is first accessed. If the row does not exist, accessing the proxy throws EntityNotFoundException (or ObjectNotFoundException with the native Hibernate API):

// Hibernate Session API
User proxy = session.load(User.class, 42L);
// No SQL yet — proxy is returned immediately
System.out.println(proxy.getName()); // SQL fires here; throws if row missing

// JPA EntityManager equivalent
User proxy = em.getReference(User.class, 42L);

When to use each

Key interview gotchas

• load() / getReference() is a performance optimization when you need an entity reference solely to satisfy a foreign key constraint — it avoids a round-trip to the database.
• In Hibernate 6, session.load() is effectively deprecated in favor of session.getReference(), which aligns with the JPA standard.
• Accessing a load() proxy after the session is closed throws LazyInitializationException.
• Both methods check the first-level cache before hitting the database — if the entity is already in the session, no SQL is issued regardless of which method you call.

In Hibernate 6 with jakarta.persistence, save() is a Hibernate-proprietary method that is effectively superseded by the JPA standard persist(). Understanding both — and their differences — is important for interviews.

save() (Hibernate-native, legacy)

save() is defined on Hibernate's Session interface. It always assigns an identifier to the entity (triggering an INSERT immediately if using IDENTITY generation), and it returns the generated identifier:

Session session = sessionFactory.openSession();
session.beginTransaction();
User user = new User("Alice");
Long id = (Long) session.save(user);  // returns the generated ID
session.getTransaction().commit();

persist() (JPA standard, preferred)

persist() is defined in the jakarta.persistence.EntityManager API. It makes a transient entity managed and persistent, but does not guarantee an immediate INSERT — the actual SQL may be deferred until flush. It returns void:

EntityManager em = emf.createEntityManager();
em.getTransaction().begin();
User user = new User("Alice");
em.persist(user);               // void return
em.getTransaction().commit();   // INSERT happens at flush/commit

Key differences

Modern recommendation

In Spring Boot 3 with Hibernate 6, always use the JPA API (persist(), merge(), remove(), find()) unless you specifically need a Hibernate-native feature. Spring Data JPA's repository.save() calls persist() for new entities and merge() for existing ones (determined by whether the ID is set).

Key interview gotchas

• session.save() called outside a transaction still executes — this can silently skip transactional rollback behavior.
• With SEQUENCE or TABLE generation strategies, persist() may still hit the database to fetch the next sequence value even before flush.
• Do not confuse Spring Data's repository.save() (which is smart about new vs existing) with Hibernate's session.save() (which always inserts).

The update() method re-associates a detached entity with the current session and schedules an UPDATE for its state. It is a Hibernate-native method on Session; the JPA equivalent is merge().

How update() works

When an entity is detached (session closed, or explicitly detached), changes to it are not tracked. update() brings it back into the persistent state:

// Entity was loaded in a previous session and is now detached
User detachedUser = ...; // fetched earlier, session is closed
detachedUser.setEmail("[email protected]");

Session session = sessionFactory.openSession();
session.beginTransaction();
session.update(detachedUser);  // re-attaches and marks for UPDATE
session.getTransaction().commit();  // UPDATE fires at flush

update() vs merge()

Modern recommendation: use merge()

merge() is safer and preferred in practice because it handles the case where a managed instance with the same ID already exists in the session:

User managedUser = em.merge(detachedUser);  // returns the managed copy

Spring Data JPA's repository.save() calls merge() internally for entities that already have an ID set.

Dirty checking vs explicit update()

For entities that are already persistent (loaded in the current session), you do not need to call update() at all — Hibernate's dirty checking mechanism detects property changes automatically and generates the UPDATE at flush time:

User user = em.find(User.class, 1L);
user.setEmail("[email protected]");
// No explicit update() call needed — dirty check handles it
em.getTransaction().commit();

Key interview gotchas

• Calling session.update() on an entity when another instance with the same ID is already in the session throws NonUniqueObjectException — use merge() instead.
• update() always schedules an UPDATE even if nothing changed; merge() may optimize this away via dirty checking on the merged instance.
• In Hibernate 6, session.update() is deprecated in favor of session.merge() to align with JPA.

The evict() method removes a specific entity instance from the first-level cache (the session cache), detaching it from the current session without deleting it from the database.

What it does

User user = session.get(User.class, 1L);
// user is now in the L1 cache and tracked for dirty checking

session.evict(user);
// user is detached — no longer tracked
// further changes to user will NOT be flushed to the database

After evict(), the object is in the detached state. The database row is unchanged.

When to use evict()

• Memory management in batch processing: when processing thousands of entities, the session cache grows indefinitely. Evicting processed entities prevents OutOfMemoryError:

for (int i = 0; i < records.size(); i++) {
    session.persist(records.get(i));
    if (i % 50 == 0) {
        session.flush();   // write to DB
        session.clear();   // evict everything (more common than evict() per-entity)
    }
}

• Preventing accidental dirty writes: evict an entity when you want to read it for reporting without risking any modification being flushed.

evict() vs clear() vs detach()

em.detach() is the JPA-standard equivalent of session.evict() and is preferred in modern code.

Key interview gotchas

• evict() does not flush pending changes first — if you modified the entity and then evict without flushing, those changes are lost.
• For bulk processing, StatelessSession is often a better choice than Session + manual eviction — it bypasses the L1 cache entirely and has lower overhead.
• session.clear() is equivalent to evicting every entity at once and is commonly used in batch loops alongside session.flush().

The remove() method (JPA standard) or delete() method (Hibernate-native) marks a persistent entity for deletion. The actual DELETE SQL is issued when the session is flushed, which typically happens at transaction commit.

Usage

// JPA standard (preferred)
User user = em.find(User.class, 1L);
em.remove(user);
// DELETE FROM users WHERE id = 1 fires at flush/commit

// Hibernate-native equivalent (legacy)
User user = session.get(User.class, 1L);
session.delete(user);   // deprecated in Hibernate 6 — use remove()

In Hibernate 6, session.delete() is deprecated. Use session.remove() (which mirrors the JPA API) instead.

Entity must be managed

The entity passed to remove() must be in the persistent (managed) state. Passing a detached instance throws IllegalArgumentException in JPA:

User detached = ...;         // detached entity
em.remove(detached);         // throws IllegalArgumentException

// Correct approach:
User managed = em.merge(detached);
em.remove(managed);

Cascade delete

If the entity has associations with CascadeType.REMOVE (or CascadeType.ALL), removing the parent also removes the associated children:

@OneToMany(mappedBy = "order", cascade = CascadeType.ALL, orphanRemoval = true)
private List items;

orphanRemoval = true also deletes child entities when they are removed from the collection, even without calling remove() explicitly.

Key interview gotchas

• remove() requires the entity to be managed — always find() first if working with an ID.
• Calling remove() on a detached object is a common mistake; the fix is to merge() first or find() again in the current session.
• orphanRemoval and CascadeType.REMOVE are related but distinct: orphanRemoval fires when the child is disassociated from the collection; CascadeType.REMOVE fires when the parent is deleted.
• The DELETE SQL is deferred until flush — within the same transaction you can still cancel by rolling back.