Transaction Management in Spring

Transaction in Spring

Here I will tell you about the transaction management in Spring framework. I will later also show you with examples how programmatic and declarative transaction management happen in Spring framework. A transaction is a logical unit of work that contains one or more statements with the following features:

  • A transaction is an atomic unit.
  • The effects of all 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.

ACID Property

The concept of transaction can be described by 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 where how transaction management is taken care. 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 changes performed by 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.

Transaction in Spring Framework

In Spring framework there are two choices for transactions, such as, Global and Local transactions.

Global Transaction

Global transaction has the following characteristics:

  • 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 web service or jms

Local Transaction

Local transaction has the following characteristics:

  1. Resource specific so works with single resource
  2. Easier to use but has limitation because cannot be used across multiple transactional resources

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

Abstraction in Spring Transaction

This part taken from http://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/transaction.html

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.

Types of Spring Transaction Management

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

Propagation Behavior in Spring Transaction

Following are the behaviors for Spring Transaction:

REQUIRED

  • 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

REQUIRES_NEW

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

NESTED

  • commit or rollback happens in the same transaction with savepoints

MANDATORY

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

NEVER

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

NOT_SUPPORTED

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

SUPPORTS

  • 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

Examples

That’s all about the transaction management in Spring framework.

Leave a Reply

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