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.
In Spring there are two choices for transactions Global and Local.
enables to work with multiple resources such as relational databases and message queues
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
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.