Object State in Hibernate

The state of an object reflects the values contained in the attributes of an object at a given time. So whenever the values change, the state also changes to reflect the current values. The total number of states traversed by an object to reach its initial state is known as the life-cycle of the object. Following are the states that form the life-cycle of a persistent object, also known as life-cycle of persistence:


1. Transience
2. Persistence
3. DetachmentThese are the states of an object. Starting from the transient state, moving on to the persistent state and reaching the detached state, this image should help you understand it better:

Each of the state transitions is associated with a task or an operation in object-oriented lingo. The details of what each state does to the persistent object and the operations that initiate the state transitions are as follows:
1. Transient State:Transient is the state of an object when it is not associated with any database. Any object instantiated using the new operator is in this state. Since they are not associated with any row of a table, they are destroyed (or become eligible to be collected by the garbage collector). Transient objects don’t come under the context of a transaction. That means if the values of a transient object are updated, calling the rollback() method doesn’t undo the changes made to the object.
2. Persistent State:An object is said to be in a persistent state when it has a database identity. An object having a database identity simply means that the identity of the object has been set using the primary key value of the table row it represents. In short, when the identity of the object contains the value of the primary key of the table row it reaches a persistent state. To make any transient object persistent, the save method of the Persistence manager has to be called. The most important characteristic feature of an object in the persistent state is that it takes part in transactional activities.
Even in the persistent state, the object stays in different states. Until the commit() method of transaction management is called with the object as a parameter, the object remains in the new state. Whenever any value held by a persistent object changes, the object becomes dirty. This state is not visible to the application. The trick used by Hibernate is known as Transparent Transaction-Level Write-Behind. The framework does this by delaying the synchronization of the object to the database table and then hides the details from the application.
This feature leads us to another feature where only those column values are updated which are modified. To do so the dynamic-update attribute of the node of the mapping file is used. Finally an object in the persistent state can be made transient by calling the delete() method of the Persistence manager with the object as a parameter.
3. Detached State:In Hibernate, when the transaction completes by calling the close() method on the Session object, the instances of persistence class lose their association with the Persistence manager. Thus the detached state is attained. In this state the object is no longer in sync with the database. Also Hibernate doesn’t care about the modifications being done to the object, as the object is no longer under the management of Hibernate. Though the Persistence or Transaction manager is no longer managing the object, it still contains the persistent data (data contained in the row of the corresponding table). This property makes it the most eligible candidate to be used as a Data Transfer Object in a multi-layered architecture.
How does this look in code? It looks something like this:
Session sess = sf.openSession();
Order o=new Order(); //transient state
// search and return
Query q = session.createQuery("from Order order where”+
+”order.id=:id");
q.setString(“id”,name);
List result = q.list();
if (list.size() == 0) {
System.out.println("No Order having id "
+ name);
System.exit(0);
}
o = (Order) list.get(0);//Persistent state
sess.close();

o.getOrderDate();//o is now detached
That clears the smoke around the life-cycle of a Persistent object. Now we can move on to more pressing issues -- issues related to associations and association mappings