Managing Transactions with Hibernate
(Page 1 of 4 )
This article explains how Hibernate handles sessions and transactions, and why those are important to a database-based applications. It also explains how core APIs take part in session and transaction management, and more.
In any database-based application, CRUD operations form the foundation stone. However, it is the optimization and concurrency management techniques that actually determine the robustness and scalability of the application. Till now I have centered my discussions of Hibernate on techniques for CRUD operations. But from this point onwards, the discussion will be towards using the transaction and concurrency control functionalities of Hibernate to strengthen the CRUD operations.
These functionalities, along with the fetch optimization techniques and patterns, answer the issues of scalability, integrity and consistency. In the first section below I give details about transaction and session management in the context of Hibernate. The second section will be about the core APIs taking part in session and transaction management. In the third section (broken into two parts for manageability), the thread local variables will be discussed and applied on transaction management APIs to create a factory class for session and transaction management.
Understanding Session and Transaction
By definition, a session is the conversation between a client and server from the moment the client logs in to the moment the client logs off. In the same context, a transaction is “a series of operations that appear to execute as one large, atomic operation.” Before going into the details of how Hibernate handles sessions and transactions, it is important to understand how the underlying layers handle transactions. These layers are the database and JDBC. The interesting point about the layered architecture is that each layer abstracts out the complexities of the layer underneath it.
First, let's look at a database transaction. A database always groups a set of CRUD operations. Such a group is a transaction in the context of a database. The transaction is deemed complete only when a commit or rollback is issued, which guarantees the atomicity of the transaction. In other words, if any of the participating operations (Insert, Delete, update or Retrieve) fails, then the complete transaction is rolled back. This is done to ensure the integrity of the data. Following is the state diagram of states during a transaction.
If the transaction contains only one database operation, then the transaction's completion depends on the success or failure of that operation. For example, if the transaction contains the insertion operation, then on the success of the operation, the transaction is committed; on its failure, the transaction is rolled back.
Now consider a situation where the transaction contains a couple of insert operations, an update and two or three delete operations. In this case, if the last operation in the list of operations fails, then the whole transaction (that would include the successful operations as well) would have to be rolled back.
To counter such a situation, the transaction demarcation is required. It helps in dividing the complete transaction into different points. Each point marks the successful ending of a set database operation. So on failure, the transaction can be rolled back to that particular point without having to roll back the whole transaction. The transaction demarcation more or less requires manual intervention.
Now we'll discuss JDBC transactions. The transactions done at the database level need database specific language (more often, it’s a variation of SQL). In the programming environment, the transactions take two forms, unmanaged and managed. In the case of unmanaged transactions, JDBC APIs are used to demarcate the boundaries of transactions. To do so, use setAutoCommit()(with false as parameter), and commit() or rollback() is called on a JDBC connection. For example, to set demarcation for a set of insert statements, the code block would be:
try{
conn.setAutoCommit(false);// conn is the instance of
Connection
//… insert statements
conn.commit();
}catch(Exception e){
conn.rollback();
}
Using JDBC APIs for transaction management in an environment involving multiple databases or distributed databases is impractical. It is here that Java Transaction APIs, also known as JTA, come into the picture. What really happens in the case of multiple databases is that a Transaction Manager is required. And to communicate to the Transaction Manager, JTA is required. The working and usage of JTA is a topic for some other time. For now it is enough to keep in mind that distributed database transactions require JTA.
From the above points it is clear that JTA sits above JDBC and JDBC encapsulates the details of communication with the database server. Now let's move on to Hibernate. To make things interesting, Hibernate adds one more layer of encapsulation. Each of the transactions are wrapped in a session. A session can have n- number of transactions. Since each transaction can be as long as the session, sometimes the session itself is considered a unit of work. Pictorially, this can be represented as follows:
or
In the above diagrams, S represents the session object and T represents the transaction object. This also brings out the point that, just as all the connection and session aspects of communication with the database server are abstracted out by the Session object, in the same way the transaction object abstracts out all the transaction related details. This brings us to the next section: core APIs involved in transaction management.
Next: Transactions: Core APIs >>
More Java Articles
More By A.P.Rajshekhar
