Transaction Management
Transaction is a unit of work performed by Front End applications on Back End System.
E.g.
- Deposit some amount in an Account.
- Withdraw some amount from an Account
- Transfer some amount from one account to another account
In database applications, Every Transaction must follow ACID properties
1. Atomicity
This property will make the Transaction either in SUCCESS state or in FAILURE state. In Database related applications, if we perform all operations then the Transaction is available in SUCCESS State, if we perform none of the operations then the Transaction is available in FAILURE state.
2. Consistency
In database applications, Before the Transaction and After the Transaction Database state must be in stable.
3. Isolation
If we run more than one Transaction on a single Data item then that Transactions are called as “Concurrent Transactions”. In Transactions Concurrency, one transaction execution must not give effect to another Transaction, this rule is called as “Isolation” property.
4. Durability
After committing the Transaction, if any failures are coming like Power failure, OS failure etc. after getting the System if we open the transaction then the modifications which we performed during the transaction must be preserved.
In JDBC, to perform Atomicity property we have to change Connections auto-commit nature and we have to perform either commit() or rollback() at the end of Transaction.
Connection con = DriverManager.getConnection(---); con.setAutoCommit(false); try{ ---instructions----- con.commit(); } catch(Exception e){ e.printStacktrace(); con.rollback(); }
In Hibernate applications, if we want to manage Transactions Atomicity property then we have to use the following steps.
- Declare Transaction Before try.
- Create Transaction object inside try block.
- Perform commit() operation at end of Transaction.
- Perform rollback() operation at catch block.
E.g
Transaction tx = null; try{ ----- tx = session.beginTransaction(); ---- ----- tx.commit(); } catch(Exception e){ tx.rollback(); }
If we execute more than one transaction on a single data item then that transactions are called as Concurrent Transactions. In Transactions concurrency we are able to get the following data consistency problems while executing more than one transaction at a time.
- Lost Update Problem
- Dirty Read Problem
- Non Repeatable Read Problem
- Phanthom Read Problem
1. Lost Update Problem
In Transactions concurrency, if one transaction performs updations over the data without commit operation, meanwhile, other transactions perform updations with commit operation then the first transaction updations are lost, this data consistency problem is called as Lost Update problem.
2. Dirty Read Problem
In Transactions concurrency, if one transaction perform updations over data without performing commit / rollback, meanwhile if other Transaction perform Read operation over the uncommitted data without performing commit/rollback operations, in this context, if first transaction perform Rollback operation then the read operation performed by second transaction is Dirty Read, this problem is called as Dirty Read problem.
3. Non-Repeatable Read Problem
In Transactions concurrency, one transaction performs continuous read operations to get same results, meanwhile, between two read operations another transaction performs update operation over the same data, in this context, in the next read operation performed by first transaction may not get same repeatable results, this problem is called as Non-Repeatable Read Problem.
4. Phantom Read Problem
In Transactions concurrency, one transaction perform read operation continuously to get same no of results at each and every read operation , meanwhile, other transactions may perform insert operations between two read operations performed by first transactions, in this context, in the next read operation performed by first transaction may not generate the same no of results, this problem is called as “Panthom Read” Problem, here the extra records inserted by second transaction are called as “Phantom Records”.
There are two types of Transactions
1. Local Transaction
2. Global Transaction
1. Local Transaction
Local transactions are specific to a single transactional resource like a JDBC connection. Local transaction management can be useful in a centralized computing environment where application components and resources are located at a single site, and transaction management only involves a local data manager running on a single machine. Local transactions are easier to be implemented.
2. Global Transaction
Global transactions can span multiple transactional resources like transaction in a distributed system. Global transaction management is required in a distributed computing environment where all the resources are distributed across multiple systems
A distributed or a global transaction is executed across multiple systems, and its execution requires coordination between the global transaction management system and all the local data managers of all the involved systems.
Transaction Support in Spring
Spring provides extensive support for transaction management and help developers to focus more on business logic rather than worrying about the integrity of data in case of any system failures. Spring Transaction Management is providing the following advantages in enterprise applications:
1. Spring Supports Declarative Transaction Management. In this model, Spring uses AOP over the transactional methods to provide data integrity. This is the preferred approach and works in most of the cases.
2. Spring Supports most of the transaction APIs such as JDBC, Hibernate, JPA, JDO, JTA etc. All we need to do is use proper transaction manager implementation class.
- org.springframework.jdbc.datasource.DriverManagerDataSource for JDBC transaction management
- org.springframework.orm.hibernate3.HibernateTransactionManager for Hibernate as ORM tool.
- Support for programmatic transaction management by using TransactionTemplate or PlatformTransactionManager implementation.
To represent ISOLATION levels Spring Framework has provided the following Constants from “org.springframework.transaction .TransactionDefinition”.
1. ISOLATION_DEFAULT: It is default isolation level; it will use the underlying database provided default Isolation level.
2. ISOLATION_READ_UNCOMMITTED: It will not resolve any ISOLATION problem, it represents dirty read problem, non-repeatable read problem, phantom read problem.
3. ISOLATION_READ_COMMITTED: It will resolve dirty read problem, but, it will represent non-repeatable read problem and phantom read problem.
4. ISOLATION_REPEATABLE_READ: It will resolve dirty read problem and non-repeatable read problem, but, It will represent phantom read problem.
5. ISOLATION_SERIALIZABLE: It will resolve all ISOLATION problems like dirty reads, non-repeatable read, and phantom read Problems.
To set the above Isolation level to TransactionTemplate then we have to use the following method.
public void setIsolationLevel(int value)
E.g
public void setIsolationLevel(int value)