Understanding Hibernate ORM: Save/Get Process, Object Lifecycle, Caching, and Transaction Concurrency

Introduction to ORM

Object Relational Mapping (ORM) is a specification that bridges the gap between object‑oriented programming and relational databases by using metadata to automatically persist Java objects to relational tables.

Save and Get Execution Flow

save:

Identify the object's class (e.g., user.getClass()) and the corresponding mapping file (User.hbm.xml) to determine the table name.

Use introspection to read the object's properties such as id and name.

Map each property to its column name based on the mapping file.

If the primary‑key generation strategy is native, the primary key is omitted from the INSERT statement; the generated SQL looks like INSERT INTO t_user(uname) VALUES (?), where the placeholder is filled by the object's getter.

get:

Locate the class and mapping file to resolve the table name.

Find the column name for the <id> element (e.g., uid) and build the SELECT statement.

Execute the query, then instantiate a User object and populate its fields by invoking the appropriate setters.

Difference Between get and load

get

sends a SELECT immediately; load returns a proxy and delays the SELECT until a non‑identifier property is accessed (lazy loading). load never returns null; if the row does not exist, an exception is thrown when the proxy is accessed, whereas get returns null when no row is found.

The proxy created by load must be initialized before the session closes, otherwise a "no session" error occurs; Hibernate.initialize(proxy) can solve this.

Lifecycle of Persistent Objects

The state of an object determines when SQL statements are issued. The four states are:

State

Description

Characteristics

Transient

Newly created with new, not persisted, not in a session.

No OID, not in session.

Persistent

Persisted and stored in the session cache.

Has OID, in session.

Detached

Persisted but no longer associated with a session.

Has OID, not in session.

Removed

Associated with a session and marked for deletion.

Has OID, in session, will be deleted.

Session methods only change the object's state; SQL is typically flushed to the database when the transaction commits, which resolves the three common questions about when INSERT, DELETE, and UPDATE statements are issued.

Second‑Level Cache

First‑level cache resides in a Session and is limited to the session’s lifespan. A second‑level cache is attached to the SessionFactory, shared across the entire application, and is consulted after the first‑level cache before hitting the database.

Transaction Concurrency Issues

Two types of lost‑update problems can occur:

Type 1: Transaction A rolls back and overwrites the committed changes of Transaction B.

Type 2: Transaction A commits after Transaction B, causing B’s updates to be lost.

Solutions are:

Pessimistic Lock – acquire a database lock using SELECT … FOR UPDATE before reading the data.

Optimistic Lock – assume no conflict, but verify a version or timestamp during update; if a conflict is detected, the transaction fails.

Hibernate recommends using a version column for optimistic locking.

Source: http://www.jianshu.com/p/44f641fd8363