November 23
transactions in a Spring context - Take 1
Posted by AjaySpring as a framework has made a lots of things much simpler for developers. Transactions is one of the area that Spring has simplified a lot. Have you ever wondered how the nitty gritty details of transaction worked in Spring? Well let me share some of what I learnt
What is a transaction?
A Transaction is defined as an indivisible unit of work. It always follows the ACID properties.
- Atomicity- all or none principle - complete the transaction in it’s entirety or do none of it.
- Consistency – do a drew brees (:-P ) - as you go from one state to another, data integrity should be maintained
- Isolation – transactions should not effect each other
- Durability – persistent state should be maintained.
A transaction can either end as a commit or a rollback.
Transaction models
There are many different transaction models available: Local transaction model, programmatic transaction model, declarative transaction model.
- Local transactions are resource specific, for example a transaction associated with JDBC. The local resource manager handles these transactions. With this model the developer will manage the connections to the transaction manager. JDBC transactions are controlled by DBMS’s transaction manager. The Connection object supports transaction demarcation. JDBC has auto commit turned on by default, so commit is done after each SQL statement executes. The problems with this model is that it introduces developer errors when coding the connection logic.
- Programmatic transaction model leverages JTA. The developer writes code to manage the transaction and not the connection as in the local transactions. The UserTransaction interface comes into play in EJBs and uses the begin(), commit(), rollback() functions. Spring uses TransactionTemplate to perform the same task with the execute() method that takes a TransactionCallback object. The main disadvantage of this method is that lot of responsibility rests on the shoulders of developers to make sure they handle the transaction semantics properly.
- Declarative transaction model is commonly known as Container Managed Transaction in the EJB world. The general idea behind this is that the container will manage the commit or rollback of the transaction, the developers will only to tell the container how to manage the transaction through configuration parameters – ejb-jar.xml in case of EJBs or ApplicationContext.xml in Spring. In Spring we use the TransactionProxyFactoryBean to implement this transaction model. EJB3.0 introduces the use of annotations for this transaction model. We also need to tell the container how to manage the transaction. This is done using a TransactionAttributeSource bean associated with a transaction attribute which has 6 different settings- Required, Mandatory, RequiresNew, Supports, NotSupported, Never
When do we use programmatic transaction model?
Usually programmatic transactions are useful when user we have client initiated transactions. If a client is making multiple remote service calls for a request, then transaction is maintained on the client side.
Another reason to use this methodology is if using JTA is very expensive in terms of performance. In such cases where we might need to squeeze every ounce of performance, so we might decide to use JTA only when absolutely required. This is called localized JTA transactions.
Another scenario is when there are long running transactions. In EJB’s these are handled using stateless session beans, where you might have multiple stateless session bean methods as a part of a single transaction.
For all other situation is is advisable to use the declarative transaction model.
JTS and JTA
Now we need to understand the difference between JTA and JTS. JTA is the interface developers use to manage transactions. The JTS or Java Transaction Service on the other hand is an underlying service that implements JTA and provides that to application servers. So essentially JTA provides the interface and JTS is the implementation similar to the relation between JDBC and database drivers.