Transaction Management in Hibernate

Transaction Management in Hibernate

Transaction: Transaction simply means a unit of work, which is atomic. If only one step fails, then the whole unit of work fails.

When we consider database, Transaction groups a set of statements/commands 
which gets committed together.If a single statement fails, whole work will be 
rolled back.

Transactions can be described using ACID criteria.
ACID means:
A : Atomicity: In a Transaction If only one step fails, the whole unit of work must fail.This is known as atomicity
C : Consistency : The Transactions operate on Consistent data. I.e. This data is hidden from other concurrently running transactions. The data is clean and consistent.
I : Isolation: It means when a transaction is being executed, it will not be visible to other concurrently running transactions.This means, any changes done to the existing data during a transaction, before transaction finishes, is not visible to other active transactions. They work on consistent data.
D : Durable: Also the changes done in a transaction are durable. Even if server / system fails after a transaction, the changes done by a successful transaction are permanent / persistent.

So a database transactions involve a set of SQL statements, which either succeeds or fails. If any one of the statement fails in between,the execution of subsequent statements are aborted and all changes done by the previous SQL statements will be rolled back.
In complex applications, which involve different database actions, one should set boundries for a transaction. This means beginning and end of the transaction should be decided. This is called 'Transaction demarcation'. If an error occurs (either while executing operations or when committing the transaction), you have to roll back the transaction to leave the data in a consistent state.

This can be done in 2 ways.
1. In a programmatic manner by explicitly setting boundaries in code or using JTA API.
2. Setting Transaction boundaries by declarative manner, specifying transaction boundaries to managed containers like EJB container.

Transaction demarcation using code:
This technique requires extra coding. In simple JDBC, transactions can begin by calling setAutoCommit(false) on a JDBC Connection and end it by calling commit(). You may, at any time, force an immediate rollback by calling rollback().
In a system that manipulates data in several databases, a transaction may involves access to more than one resource. In this case, you can't achieve atomicity with JDBC alone. You need a transaction manager that can handle several resources in one system transaction. Such transaction-processing systems expose the Java Transaction API (JTA) for interaction with the developer. The main API in JTA is the UserTransaction interface with methods to begin() and commit() a system transaction.

In Hibernate, it has Transaction interface. They work on top of JTA. The main benefit of using Transaction interface, is tight integration with persistence context management-for example, a Session
is flushed automatically when you commit.

Hibernate Example:
     Session session = null;
     Transaction tx = null;
        try {
                  session = sessionFactory.openSession();
                  tx = session.beginTransaction();
                  doTheAction(session);
                  tx.commit();
            }
         catch (RuntimeException ex) 

                  {
                       tx.rollback();
                  } 

             finally
                 {
                      session.close();
                 }

In the above example, a transaction started by session.beginTransaction(). In Hibernate A JDBC Connection from the connection pool is obtained only when the database transaction begins. The call to beginTransaction() translates into setAutoCommit(false) on the fresh JDBC Connection. When you call commit() on the Transaction, Session is flushed. After you commit the transaction (or roll it back), the database connection is released.