Transaction handling in Spring

When we are dealing with data and databases, transaction management is the most important thing. 

How JDBC handles transactions

import java.sql.Connection;

Connection connection = dataSource.getConnection(); 

try (connection) {

    connection.setAutoCommit(false); 

    // execute some SQL statements...

    connection.commit(); 

} catch (SQLException e) {

    connection.rollback();

}

Set isolation levels in JDBC

connection.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);

Plain JDBC transaction handling vs Spring transaction handling

• Don't need to open or close database connections, you can use Transaction callbacks or a JDBC template
• You don't need to catch SQLExceptions, Spring will convert them into run-time exceptions.
• Easy to use Spring ecosystem

Transaction management with Spring 

• In Spring Boot it automatically enabled transaction management. 
• But if you are using Spring MVC, you need to add the @EnableTransactionManagement annotation in the main class
• @Transactional annotation tells Spring that a transaction is required to execute a method or class.
• Actually, Spring @Transactional annotation converts the method into a simple JDBC transaction model

@Transactional

public List<Employee> getEmployees() {

    Connection connection = dataSource.getConnection(); 

    try (connection) {

        connection.setAutoCommit(false); 

        return employeeRepository.findAll();

        connection.commit(); 

    } catch (SQLException e) {

        connection.rollback(); 

    }

}

How the transaction works in Spring

Look at the following control and service

@RestController

@RequestMapping("/api/employee")

public class EmployeeController {

    @Autowired

    public EmployeeController(EmployeeService employeeService){

        this.employeeService=employeeService;

    }

    private EmployeeService employeeService;

    @GetMapping("/getEmployees")

    public List<Employee> getAllEmployees(){

        return employeeService.getEmployees();

    }

}

@Service

@Transactional

public class EmployeeService {

    @Autowired

    public EmployeeService(EmployeeRepository employeeRepository){

        this.employeeRepository=employeeRepository;

    }

    private EmployeeRepository employeeRepository;

    public List<Employee> getEmployees() {

        return employeeRepository.findAll();

    }

}

• When EmployeeController injects the EmployeeService, Spring generates a dynamic CGLib proxy object that wraps the service object and provides the required codes to manage the transaction.
• The proxy delegates handling transactions to the transaction manager.
• Once the transaction is completed, it will commit or roll back the transaction. 

Physical transaction vs logical transaction

Look at the following example

@Service

public class EmployeeService {

    @Autowired

    private AccountService accountService;

    @Transactional

    public void getAccountDetails() {

       accountService.createAccountDocument();

    }

}

@Service

public class AccountService {

    @Transactional

    public void createAccountDocument() {

    }

}

• Here EmployeeService getAccountDetails() method calls another @Transactional method in AccountService
• According to the ACID properties, it should be one transaction.
• Spring calls this a physical transaction. It is just actual JDBC connections.
• But internally there are two logical transactions. The first one in EmployeeService and another one in AccountService
• If we change the propagation type in createAccountDocument( ) we can change it to have two physical connections.

Propagation levels in Spring

• You can set propagation levels like @Transactioanl(propagation=Propagation.REQUIRED) There are few propagation levels in the Spring.
• It explains the way of creating a transaction

Types of propagation levels

• REQUIRED
• This is the default propagation level
• It says I need a transaction either open one or use the existing one
• It means it always executes in a transaction
• SUPPORTS
• If a current transaction exists, then it uses. If not it gets executed without a transaction. 
• It means it may use or not a transaction.
• MANDATORY
• This requires an existing physical transaction, if not it will cause an exception
• REQUIRES_NEW
• Requesting a completely own physical transaction
• If already there is a transaction, it will be suspended and create a new transaction
• NOT_SUPPORTED
• Always executes without a transaction.
• If there is a transaction, it gets suspended
• NEVER
• Always executes without a transaction
• This means, no physical transaction will exist. If found, it will cause an exception
• NESTED
• This is the same as REQUIRED but it uses save-points.
• Simply it means inner logical transactions may roll back independently.

Read operations in a transaction

• Dirty read
• This occurs when a transaction reads data that is written but not committed by another transaction.
• T2 updates a row, but not committed and T1 reads the row. But if T2 rollback, the value which is read by T1 is not valid.
• Nonrepeatable read
• This occurs when a transaction reads the same data twice but gets different values.
• T1 reads a row, then T2 updates the row and committed. Then T1 reads the row and gets a different value.
• Phantom read
• This occurs when a transaction executes a query and gets a value set. Then get additional values as well in different execution.
• T1 reads some data. T2 adds some additional data in another transaction. Then T1 reads data and gets an additional data set.

Isolation levels in Spring

• Isolation.DEFAULT
• Use the default isolation level in the underlying database
•  Isolation.READ_COMMITTED
• This prohibits reading uncommitted data
• If you use this, dirty reads will be prevented
• Isolation.READ_UNCOMMITTED
• This allows to read one transaction update a row, but not committed and other transaction can read data even not committed.
• All read operations, dirty, non-repeatable, and phantom can occur.
• Isolation.REPEATABLE_READ
• This prohibits reading uncommitted data and also prohibits one transaction reads a row and another transaction alters the data.
• This prevents both dirty read and nonrepeatable reads
•   Isolation.SERIALIZABLE
• all dirty reads, nonrepeatable reads, and phantom reads are prevented

rollbackFor and noRollbackFor

• rollbackFor can be used to indicate which exceptions cause the transaction rollback
• noRollbackFor can be used to indicate which exception, not cause the transaction rollback

readOnly

• The default value is false
• We can use, readOnly=true  for search operations