We know that Hibernate works with plain old Java objects (POJO). In raw form (without hibernate-specific annotations), it will not be able to identify these POJO classes.
But when the POJOs are properly annotated with required annotations then hibernate will be able to identify and work with them e.g. store them in the database, update them, etc. These POJOs are said to be managed by hibernate’s persistent context or hibernate entities.
A picture speaks a thousand words. Let us understand how the transition happens between the various lifecycle states of an entity.
1. Entity Lifecycle States
Given an instance of a class that is managed by persistent context, it can be in any one of four different persistence states (known as hibernate entity lifecycle states):
- Persistent or Managed
Transient entities exist in heap memory as normal Java objects. Hibernate does not manage transient entities. The persistent context does not track the changes done on them.
- In simple words, a transient entity has neither any representation in the datastore nor in the current Session.
- A transient entity is simply a POJO without any identifier.
EmployeeEntity employee = new EmployeeEntity();
1.2. Persistent or Managed
Persistent entities exist in the database, and Hibernate’s persistent context tracks all the changes done on the persistent entities by the client code.
A persistent entity is mapped to a specific database row, identified by the ID field. Hibernate’s current running Session is responsible for tracking all changes done to a managed entity and propagating these changes to database.
We can get persistent entity in either of two ways:
- Load the entity using get() or load() method.
- Persist the transient or detached entity using persist(), save(), update() or saveOrUpdate() methods.
EmployeeEntity employee = session.load(1); //or EmployeeEntity employee = new EmployeeEntity(); session.save(employee);
Detached entities have a representation in the database but these are currently not managed by the Session. Any changes to a detached entity will not be reflected in the database, and vice-versa.
A detached entity can be created by closing the session that it was associated with, or by evicting it from the session with a call to the session’s
session.close(); //or session.evict(entity);
This temporary separation of the entity and the database is shown in the image below.
One reason you might consider doing this would be to read an object out of the database, modify the properties of the object in memory, and then store the results some place other than your database. This would be an alternative to doing a deep copy of the object.
Note that in order to make a persistent entity from a detached entity, the application must re-attach it to a valid Hibernate Session. A detached instance can be associated with a new Hibernate session when your application calls one of the
save() methods on the new session with a reference to the detached object.
After the method call, the detached entity would be a persistent entity managed by the new Hibernate session.
Removed entities are objects that were being managed by Hibernate (persistent entities, in other words) and now those have been passed to the session’s
When the application marks the changes held in the Session as to be committed, the entries in the database that correspond to removed entities are deleted.
- The newly created POJO object will be in the transient state. The transient entity doesn’t represent any row of the database i.e. not associated with any session object. It’s a plain simple java object.
- A persistent entity represents one row of the database and is always associated with some unique hibernate session. Changes to persistent objects are tracked by hibernate and are saved into the database when commit calls happen.
- Detached entities are those who were once persistent in the past, and now they are no longer persistent. To persist changes done in detached objects, you must re-attach them to hibernate session.
- Removed entities are persistent objects that have been passed to the session’s
remove()method and soon will be deleted as soon as changes held in the session will be committed to the database.
Happy Learning !!