Hibernate Operations

Both get() and load() retrieve a persistent entity by primary key, but they differ in database access timing and missing-record behavior. This is one of the most frequently asked Hibernate interview questions.

get() / find() — eager, immediate

Hits the database immediately. Returns the fully initialized entity, or null if no row exists with that ID:

// Hibernate native
User user = session.get(User.class, 42L);  // SQL fires now
if (user == null) { /* not found */ }

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

Both methods check the first-level (session) cache first — if the entity is already loaded, no SQL is issued.

load() / getReference() — lazy, proxy-based

Returns a proxy object immediately, without hitting the database. The SQL fires only when a non-ID property is first accessed. If the row does not exist, ObjectNotFoundException / EntityNotFoundException is thrown at that point — not when load() is called:

// Hibernate native
User proxy = session.load(User.class, 42L);  // no SQL
System.out.println(proxy.getName());         // SQL fires here; throws if missing

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

Comparison table

Key interview gotchas

• getReference() / load() is useful when you only need to set a relationship without loading the data (e.g., order.setUser(em.getReference(User.class, userId))).
• In Hibernate 6, session.load() is deprecated — use session.getReference() to align with JPA.
• Accessing a getReference() proxy after the session is closed throws LazyInitializationException.
• If the entity is already in the L1 cache, getReference() may return the real entity rather than a proxy.

Both save() and persist() make a transient entity persistent, but they differ in API ownership, behavior, and return values. Interviewers ask this to test knowledge of Hibernate-native vs JPA-standard APIs.

save() — Hibernate-native (legacy)

• Defined on Hibernate's Session interface.
• Returns the generated identifier (Serializable).
• Can be called outside a transaction (issues INSERT immediately — risky).
• If the entity already has an ID set, it may still attempt an INSERT.

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

persist() — JPA standard (preferred)

• Defined on jakarta.persistence.EntityManager.
• Returns void.
• Must be called within an active transaction; throws TransactionRequiredException otherwise.
• Defers the INSERT until flush time (except with IDENTITY generation, which requires an immediate INSERT to obtain the ID).

EntityManager em = emf.createEntityManager();
em.getTransaction().begin();
User user = new User("Alice");
em.persist(user);               // void — INSERT deferred to flush
em.getTransaction().commit();

Comparison table

Modern recommendation

Use persist() in all new code. Spring Data JPA's repository.save() internally calls persist() for new entities (no ID) and merge() for existing ones (ID present).

Key interview gotchas

• save() called without a transaction can produce an INSERT that is never rolled back if the surrounding logic fails.
• With SEQUENCE generation, persist() still hits the database to get the next sequence value even before the flush.
• Calling save() on an already-persistent entity is a no-op in terms of INSERT but may cause unexpected behavior — use merge() or rely on dirty checking instead.

Both update() and merge() re-synchronize a detached entity's state with the database, but they handle the session state differently — merge() is the JPA standard and the safer choice.

update() — Hibernate-native

Re-attaches a detached entity to the current session. The entity becomes managed again and its full state is scheduled for UPDATE at flush time. Throws NonUniqueObjectException if a managed instance with the same ID is already in the session:

User detached = ...;  // detached — from a closed session
detached.setEmail("[email protected]");

Session session = sf.openSession();
session.beginTransaction();
session.update(detached);  // re-attaches detached object
session.getTransaction().commit();  // UPDATE fires

merge() — JPA standard (preferred)

Copies the state of the detached object onto a managed instance (either an existing one in the session or a newly loaded one). Returns the managed entity — the original detached instance is not modified or re-attached:

EntityManager em = emf.createEntityManager();
em.getTransaction().begin();
User managed = em.merge(detached);   // returns managed copy
// Use 'managed', not 'detached', from here on
em.getTransaction().commit();

Comparison table

Modern recommendation

Always use merge(). It is JPA-standard, portable, and handles the duplicate-in-session scenario safely. Spring Data JPA's repository.save() uses merge() for existing entities (those with a non-null ID).

Key interview gotchas

• After merge(), always use the returned managed instance — the original detached object is not re-attached.
• session.update() is deprecated in Hibernate 6 in favor of session.merge().
• merge() may issue a SELECT before the UPDATE if the entity is not already in the session cache.
• Neither update() nor merge() is needed for entities that are already persistent in the current session — dirty checking handles updates automatically.

saveOrUpdate() is a Hibernate-native convenience method that determines whether to INSERT or UPDATE based on the entity's identifier and state. It is the predecessor to Spring Data's repository.save().

How it works

Hibernate applies the following logic:

1. If the identifier is null (or zero for primitives) → treats the entity as transient and calls save() (INSERT).
2. If the identifier is set → treats the entity as detached and calls update() (UPDATE).
3. If the entity is already in the session cache → no-op or refresh.

Session session = sf.openSession();
session.beginTransaction();

User newUser = new User();
newUser.setName("Alice");
session.saveOrUpdate(newUser);   // INSERT — id is null

User existing = new User();
existing.setId(5L);
existing.setName("Bob");
session.saveOrUpdate(existing);  // UPDATE — id is set

session.getTransaction().commit();

Hibernate 6 status

saveOrUpdate() is deprecated in Hibernate 6. The recommended replacements are:

• session.persist() for new (transient) entities.
• session.merge() for detached entities.
• Spring Data JPA: repository.save() encapsulates the same logic using Persistable or @Version checks.

Spring Data JPA equivalent

Spring Data's CrudRepository.save() implements the same pattern:

// Spring Data — works for both new and existing entities
userRepository.save(user);
// Internally: persist() if isNew(), merge() otherwise

isNew() is determined by: null ID, or implementing Persistable with a custom isNew() method, or using @Version field (null version = new).

Key interview gotchas

• saveOrUpdate() can cause NonUniqueObjectException if a managed instance with the same ID exists in the session — the same pitfall as update().
• Relying on a null ID to detect "new" entities only works with auto-generated IDs; if IDs are assigned manually, use Persistable or @Version.
• In Spring Data, save() returns the managed entity after persist/merge — always use the returned value, not the original object.

evict() and remove() both operate on entities in the session, but they serve opposite purposes: evict() detaches an entity without touching the database, while remove() marks it for deletion from the database.

evict() / detach() — removes from session cache only

Detaches the entity from the session. The object moves from the persistent to the detached state. The database row is unchanged. No SQL is generated:

User user = session.get(User.class, 1L);  // persistent
session.evict(user);                        // detached — no SQL
// Changes to user after this point will NOT be flushed

// JPA standard equivalent
em.detach(user);

Common use case: batch processing, where you flush() + evict() (or clear()) in a loop to control memory usage.

remove() / delete() — deletes from database

Marks the entity for deletion. The entity moves from persistent to removed state. A DELETE SQL is issued at flush time:

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

// Hibernate native (legacy, deprecated in H6)
session.delete(user);

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

Comparison

Key interview gotchas

• evict() before flush() discards unwritten changes — this is usually a bug unless intentional.
• session.delete() is deprecated in Hibernate 6; use session.remove() which mirrors the JPA API.
• Evicting is for memory/performance management; removing is for data deletion — they are conceptually unrelated despite both touching the session.
• After remove(), the entity's ID is still set on the Java object, but accessing the removed entity through the session after flush will not find it.