Introduction to Transaction

A transaction is a logical unit of work that contains one or more statements.
A transaction is an atomic unit.
The effects of all the statements in a transaction can be either all committed or all rolled back.

Transaction management is an important part of enterprise applications to ensure data integrity and consistency.

The concept of transactions can be described as ACID(Atomicity, Consistency, Isolation, Durability) property:

Atomicity: Atomicity requires that each transaction is “all or nothing” which means either the sequence of a transaction is successful or unsuccessful. If one part of a transaction fails then entire transaction fails.

Consistency: The database value should be consistent from state to state while any data written to the database for any combination of constraints, cascade, triggers etc.

Isolation: Each transaction must be executed in isolation in concurrent environment to prevent data corruption.

Durability: Once a transaction has been committed, the results of this transaction have to be made permanent even in the event of power loss, crashes, or errors.

For example, consider a banking system. When a bank customer transfers money from an account A to an account B, the transaction can consist of three separate operations:

Decrement the amount from account A

Increment the amount into account B

Record the transaction in the transaction journal

If all three above statements can be performed to maintain the accounts in proper balance, the effects of the transaction can be applied to the persistent storage such as database or file. However, if a problem such as insufficient funds, invalid account number, or a hardware failure prevents one or two of the statements in the transaction from completing, the entire transaction must be rolled back so that the balance of all accounts(account A and account B) is correct.

Committing a transaction means making permanent the changes performed by the statements within the transaction.

Rolling back means undoing any changes to data that have been performed by statements within an uncommitted transaction.

A distributed transaction is a transaction that includes one or more statements that update data on two or more distinct nodes of a distributed persistent storage.

A two-phase commit mechanism guarantees that all persistant storage servers participating in a distributed transaction either all commit or all undo the statements in the transaction. A two-phase commit mechanism also protects implicit DML operations performed by integrity constraints, remote procedure calls, and triggers.

Spring Transaction

In Spring there are two choices for transactions Global and Local.


enables to work with multiple resources such as relational databases and message queues
distributed transaction
requires two phase commit
very complex to configure for properly recovery

example: in a bank transfer amount from one account to another account in two steps
1. debit amount from one account using database connection
2. creadit amount to another account using webservice or jms


resource specific so works with single resource
easier to use but has limitation because cannot be used across multiple transactional resources

example: in a bank transfer amount from one account to another account within a single database using single database connection

Spring Transaction Abstraction

This part taken from

It is a notion of transaction strategy which specifies the following things

Isolation: Each transaction is executed separately.

Propagation: All code which are in a transaction scope will run only within that transaction. For example, code can continue running in the existing transaction (the common case); or the existing transaction can be suspended and a new transaction created.

Timeout: How long this transaction runs before timing out and being rolled back automatically by the underlying transaction infrastructure.

Read-only status: A read-only transaction can be used when your code reads but does not modify data. Read-only transactions can be a useful optimization in some cases, such as when you are using Hibernate.

Spring supports two types of transaction management: Programmatic and Declarative

Programmatic transaction management: You have manage the transaction with the help of programming and it gives you flexibility to customize but difficult to maintain.

Please look at this tutorial for Programmatic Transaction Management in Spring

Declarative transaction management: This option has the least impact on application code and happens using Spring AOP. You need to use only annotations or XML based configuration to manage the transactions.

Please look at this tutorial for Declarative Transaction Management in Spring

Spring Transaction Propagation Behavior

Following are the behaviors for Spring Transaction

the same transaction, if already exists, will be used in the current bean method execution context
if the transaction does not exist already then a new transaction will be created
if multiple methods configured with REQUIRED behaviour then they will share the same transaction

this behaviour means a new transaction will always be created irrespective of whether a transaction exists or not
each transaction runs independently

commit or rollback happens in the same transaction with savepoints

an opened transaction must exist otherwise container will throw an Exception

an opened transaction must not exist otherwise container will throw an Exception

if an opened transaction exists it will be paused because it is out of scope of any transaction

if an opened transaction already exists then it will be executed within that transaction
if any transaction does not exist then it will be executed in a non-transactional manner

Thanks for your reading. Please do not forget to leave a comment.


I am a professional Web developer, Enterprise Application developer, Software Engineer and Blogger. Connect me on Roy Tutorials | TwitterFacebook Google PlusLinkedin | Reddit

Leave a Reply

Your email address will not be published. Required fields are marked *