Transaction Management

1. Overview

A database transaction is a sequence of actions that are treated as a single unit of work. These actions should either complete entirely or take no effect at all. Transaction management is an important part of RDBMS-oriented enterprise application to ensure data integrity and consistency. 

2. Description

2.1 Core Concepts

The following four key properties are the core concept of a transaction,  referred to ACID.

• Atomicity: A transaction should be treated as a single unit of operation
• Consistency: Consistency of the referential integrity of the database, unique primary keys in tables
• Isolation: Each transaction should be isolated from others to prevent data corruption
• Durability: The result of transaction has to be made permanent and cannot be erased from the database due to system failure

2.2 Ways of managing Transactions

Features	Programmatic Transactions	Declarative Transactions
Coupling with Business Logic	Tightly bound	Loosely bound
Clear	Very clear	Separated, so not clear
Repetitive	Very repetitive	Just Declaration
Maintenance	Difficult	Easy
Flexibility	More flexible	Less flexible
Crosscutting Concern	Less modularized	More modularized
AOP	No AOP-wised	AOP-wised

2.3 Methods of Programmical Managing

Methods	Description
getTransaction	Returns a currently active transaction or creates a new one, according to the specified propagation behavior.
begin	Begins a transaction
commit	Commits the given transaction, with regard to its status.
rollback	Performs a rollback of the given transaction.

2.4 Declarative managing using Transactional annotation

• Propagation Options Behavior

Features	Descriptions
REQUIRED	Indicates that the target method cannot run without an active tx. If a tx has already been started before the invocation of this method, then it will continue in the same tx or a new tx would begin soon as this method is called.
REQURIED_NEW	Indicates that a new tx has to start every time the target method is called. If already atxis going on, it will be suspended before starting a new one.
MANDATORY	Indicates that the target method requires an active tx to be running. If a tx is not going on, it will fail by throwing an exception.
SUPPORTS	Indicates that the target method can execute irrespective of a tx. If a tx is running, it will participate in the same tx. If executed without a tx it will still execute if no errors. Methods which fetch data are the best candidates for this option.
NOT_SUPPORTED	Indicates that the target method doesn’t require the transaction context to be propagated. Mostly those methods which run in a transaction but perform in-memory operations are the best candidates for this option.
NEVER	Indicates that the target method will raise an exception if executed in a transactional process. This option is mostly not used in projects.

2.4.1 REQUIRED

Nested methods execute in the firstly created transaction.

2.4.2 REQURIED_NEW

Nested methods executed in a new transaction and outer transaction is suspended.

2.5 Rollback options

Features	Descriptions
rollbackFor	Default is rollbackFor=RunTimeException.class In Spring, all API classes throw RuntimeException, which means if any method fails, the container will always rollback the ongoing transaction. The problem is only with checked exceptions. So this option can be used to declaratively rollback a transaction if Checked Exception occurs.
noRollbackFor	Indicates that a rollback should not be issued if the target method raises this exception.

2.6 Isolation Level

Features	Description	Possible limits
Default	Use the default isolation level of the underlying database
READ_COMMITED	Prevents dirty read	Non-repeatable and Phantom reads
READ_UNCOMMITTED	May read data that is still uncommitted and changed by other transactions	Dirty reads
REPEATABLE_READ	Prevents dirty and non-repeatable reads	Phantom reads
SERIALIZABLE	Prevent dirty, non-repeatable, phantom reads	No concurrent transactions

2.7 Terms of Isolation issues

Features	Description
Dirty Reads	Transaction "A" writes a record. Meanwhile, Transaction "B" reads that same record before Transaction A commits. Later, Transaction A decides to rollback and now we have changes in Transaction B that are inconsistent. This is a dirty read. Transaction B was running in READ_UNCOMMITTED isolation level so it was able to read Transaction A changes before a commit occurred.
Non-Repeatable Reads	Transaction "A" reads some record. Then Transaction "B" writes that same record and commits. Later Transaction A reads that same record again and may get different values because Transaction B made changes to that record and committed. This is a non-repeatable read.
Phantom Reads	Transaction "A" reads a range of records. Meanwhile, Transaction "B" inserts a new record in the same range that Transaction A initially fetched and commits. Later Transaction A reads the same range again and will also get the record that Transaction B just inserted. This is a phantom read: a transaction fetched a range of records multiple times from the database and obtained different result sets (containing phantom records).

3. Examples

3.1 Programmatically Managing

EntityManagerFactory factory = Persistence.createEntityManagerFactory("PERSISTENCE_UNIT_NAME");                                       EntityManager entityManager = entityManagerFactory.createEntityManager();                   
Transaction transaction = entityManager.getTransaction()                  
try                                       
{  
   transaction.begin();                   
   someBusinessCode();                    
   transaction.commit();  
}                  
catch(Exception ex)                   
{                     
   transaction.rollback();  
   throw ex;                  
}

4. References

https://www.tutorialspoint.com/spring/spring_transaction_management.htm

https://dzone.com/articles/spring-transaction-management

https://www.javacodegeeks.com/2016/05/understanding-transactional-annotation-spring.html#targetText=At%20a%20high%20level%2C%20when,the%20class%20you're%20annotating.&targetText=A%20proxy%20provides%20a%20way,into%20the%20object%20being%20proxied.

https://vladmihalcea.com/dirty-read/

https://vladmihalcea.com/non-repeatable-read/

https://vladmihalcea.com/phantom-read/

https://docs.spring.io/spring/docs/4.2.x/spring-framework-reference/html/transaction.html