What is a transaction?
A transaction is a unit of work in which either all operations must execute or none of them.
For example: Transferring money from one account to another is a transaction consisting of two steps:
- Deduct the balance from the sender’s account
- Add the amount to the receiver’s account.
Now think of the situation where the amount is deducted from the sender’s account, but not delivered to receiver account due to some errors. Such issues are managed by transaction management in which both the steps are performed in a single unit of work where either both steps are performed successfully or in case anyone gets failed, it should be roll backed.
What is ACID concept in transaction?
- Atomic – atomicity makes sure that either all operations within a transaction must be successful or none of them.
- Consistent– This property makes sure that data should be in consistent state once the transaction is completed.
- Isolated– this property allows multiple users to access the same set of data and each user’s processing should be isolated from others.
- Durable – Result of the transaction should be permanent once the transaction is completed to avoid any loss of data.
What are different types of Transactions?
Developers have had two choices for transaction management: global or local transactions.
Global transactions are managed by the application server, using the Java Transaction API (JTA).For instance, global transactions provide the ability to work with multiple transactional resources (typically relational databases and message queues).Global transactions have a significant downside, in that code needs to use JTA, and JTA is a cumbersome API to use.
Previously, the preferred way to use global transactions was via EJB CMT (Container Managed Transaction): CMT is a form of declarative transaction management (as distinguished from programmatic transaction management). EJB CMT removes most but not all of the need to write Java code to control transactions. The significant downside is that CMT is tied to JTA and an application server environment. Also, it is only available if one chooses to implement business logic in EJBs. The negatives of EJB in general are so great that this is not an attractive proposition, especially in the face of compelling alternatives for declarative transaction management.
Local transactions are resource-specific: the most common example would be a transaction associated with a JDBC connection. With local transactions, the application server is not involved in transaction management and cannot help ensure correctness across multiple resources.Another downside is that local transactions are invasive to the programming model.
What are the different types of Transaction Management?
There are two types of Transaction Management:
- Programmatic Transaction Management: With programmatic transactions , transaction management code like, commit when everything is successful or rolling back if anything goes wrong is clubbed with the business logic.
- Declarative Transaction Management:Declarative transactions separates transaction management code from business logic.
Programmatic Transaction Management
- Allows you to manage transactions through programming in your source code.
This means hardcoding transaction logic between your business logic. - You use programming to manage transactions
- Flexible, but difficult to maintain with large amount of business logic. Introduces boilerplate between business logic.
- Preferred when relative less transaction logic is to be introduced.
The below is the example of Programmatic Transaction Management.
UserTransaction utx = entityManager.getTransaction();
try {
utx.begin();
businessLogic();
utx.commit();
} catch(Exception ex) {
utx.rollback();
throw ex;
}
Declarative Transaction Management
- Allows you to manage transactions through configurations or annotations.
This means separating transaction logic with business logic. - You use annotations (Or XML files) to manage transactions.
- Easy to maintain. Boilerplate is kept away from business logic.
- Preferred when working with large amount of Transaction logic.
The below is the example of Declarative Transaction Management using Spring @Transactional annotation.
@Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
public void businessLogic() {
… transactional code …
}
Programmatic or declarative transaction management?
Choosing declarative or programmatic transactions is convenience versus fine control. Programmatic approach provides a fine control on transaction boundaries, whereas declarative approach provides a great configurability using configuration files or annotations.
Programmatic transaction management is usually a good idea only if you have a small number of transactional operations. For example, if you have a web application that require transactions only for certain update operations, you may not want to set up transactional proxies using Spring or any other technology. In this case, using the TransactionTemplate may be a good approach. Being able to set the transaction name explicitly is also something that can only be done using the programmatic approach to transaction management.
On the other hand, if your application has numerous transactional operations, declarative transaction management is usually worthwhile. It keeps transaction management out of business logic, and is not difficult to configure. When using the Spring Framework, rather than EJB CMT, the configuration cost of declarative transaction management is greatly reduced.