This article extracts some Spring transaction related theories, mainly describes the characteristics of transaction, transaction propagation behavior, transaction isolation rules.

Keywords: transaction characteristics, transaction propagation, transaction isolation

Transactions are used to ensure data integrity and consistency. Like money transfers, the total amount of money does not increase or decrease.

Database transaction management has four properties (ACID) :

Atomicity Transactions are executed as a whole, either all or none. Consistency transactions should ensure that data changes from one consistent state to another consistent state and that data should not be corrupted. Isolation When multiple transactions are executed concurrently, the execution of one transaction should not affect the execution of other transactions. Durability Modifications to data for submitted transactions should be permanent.

The Spring transaction manager

  1. Transaction Management Interface

Spring in the PlatformTransactionManager defines the total transaction management interface, the interface defines the following interface to manage affairs:

GetTransaction () – getTransaction status, Spring does not manage transactions directly. Instead, it provides a transaction management interface. Other platforms (such as JDBC, Hibernate) implement transaction management themselves.

A few specific things:

The name of the transaction manager class that JDBC transaction org. Springframework). The JDBC datasource. DataSourceTransactionManager by calling Java. SQL. The Connection to Hibernateorg management affairs , springframework orm. Hibernate3. HibernateTransactionManager affairs management by the org. Hibernate. The Transaction object for Java persistence API (JPA) org. Spring Framework. The orm. Jpa. JpaTransactionManagerJpaTransactionManager and by the factory (javax.mail. Persistence. EntityManagerFactory) generated jpa EntityManager cooperation to build the Java native API affairs org. Springframework. Transaction. The jta. JtaTransactionManagerJtaTransactionManager entrust affairs management responsibility Javax.mail. Transaction. UserTransaction and javax.mail. Transaction. TransactionManager object (allows multiple transactions between multiple database management)

For JTA, refer to transactions in Java — JDBC transactions and JTA transactions

Calf takes you into Spring transactions (Spring Transaction Manager)

  1. Transaction management and AOP

Spring intercepts all business processing methods that require transaction management through AOP.

Spring transactions have several properties, which are represented by the TransactionDefinition interface:

public interface TransactionDefinition {

// Transaction propagates behavior definition

int PROPAGATION_REQUIRED = 0;

int PROPAGATION_SUPPORTS = 1;

int PROPAGATION_MANDATORY = 2;

int PROPAGATION_REQUIRES_NEW = 3;

int PROPAGATION_NOT_SUPPORTED = 4;

int PROPAGATION_NEVER = 5;

int PROPAGATION_NESTED = 6;

// Transaction isolation level definition

int ISOLATION_DEFAULT = -1;

int ISOLATION_READ_UNCOMMITTED = Connection.TRANSACTION_READ_UNCOMMITTED;

int ISOLATION_READ_COMMITTED = Connection.TRANSACTION_READ_COMMITTED;

int ISOLATION_REPEATABLE_READ = Connection.TRANSACTION_REPEATABLE_READ;

int ISOLATION_SERIALIZABLE = Connection.TRANSACTION_SERIALIZABLE;

// Default timeout period

int TIMEOUT_DEFAULT = -1;

// Get transaction propagation behavior

int getPropagationBehavior();

// Get the transaction isolation level

int getIsolationLevel();

// Get the transaction timeout

int getTimeout();

// Get whether the transaction is read-only

boolean isReadOnly();

// Get the transaction name

String getName();

}

With the interface definition and rollback rules, a transaction can have the following five basic configurations: transaction propagation behavior, transaction isolation level, transaction timeout, transaction read-only, and rollback rules

  1. Propagation behavior

Propagation Behavior refers to how to deal with a transaction when it is called by another transaction method. The invoked method may run within an existing transaction or start a new transaction and run within its own transaction.

PROPAGATION_REQUIRED Indicates that the current method must run in a transaction. If the current transaction exists, the method will run in that transaction. Otherwise, a new transaction is started, and there is only one transaction, PROPAGATION_SUPPORTS means that the current method does not need a transaction context, but if a current transaction exists, the method runs in that transaction. If the method is called alone, it is non-transactionally executed. If the method is called by another method that has a transaction, PROPAGATION_MANDATORY Means that the method must run in a transaction, and an exception is thrown if the current transaction does not exist. If a non-transactional call alone throws an exception, it must be called by another transactional method and added to the transaction. PROPAGATION_REQUIRED_NEW indicates that the current method must run in its own transaction. A new transaction will be started. If there is a current transaction, it is suspended during the execution of the method. If you use JTATransactionManager, you need to access TransactionManager to always open a new transaction, and the original calling transaction, if it exists, will be suspended until the transaction completes. PROPAGATION_NOT_SUPPORTED means that the method should not run in a transaction. If there is a current transaction, it will be suspended while the method is running. If you use JTATransactionManager, you need to access TransactionManager to always execute the method nontransactionally and suspend if the calling transaction exists. Until method execution completes PROPAGATION_NEVER means that the current method should not run in a transactional context. If a transaction is currently running, an exception is always thrown for a non-transactional execution method, otherwise an exception is thrown, PROPAGATION_NESTED indicating that the method will run in a nested transaction if a transaction already exists. Nested transactions can be committed or rolled back independently of the current transaction. If the current transaction does not exist, it behaves as PROPAGATION_REQUIRED. Note that vendor support for this propagation behavior varies. Refer to the resource manager’s documentation to see if they support nested transactions. An important concept of nested transactions is that inner transactions depend on outer transactions. When an outer transaction fails, actions taken by the inner transaction are rolled back. The failure of the inner transaction does not cause the rollback of the outer transaction.

  1. Quarantine rules

Transactions can be executed concurrently, and the isolation level defines the extent to which a transaction is affected by other concurrent transactions.

There are two tables:

Problems caused by concurrent transactions

When a transaction reads data that another transaction has modified but not committed, if the modification is rolled back, the transaction has read invalid data. Non-repeatable Read Different data is read from the same query in the same transaction. Between the two queries, another concurrent transaction updates the data. The same transaction reads different numbers of records in two identical queries. One transaction adds or deletes data between the two queries in another concurrent transaction.

Isolation level

Isolation Level Description Problems caused by concurrent transactions ISOLATION_DEFAULT Default isolation level of the back-end database ISOLATION_READ_UNCOMMITTED The lowest isolation level, Allow reading of uncommitted data change Dirty read, unrepeatable read, and unreal ISOLATION_READ_COMMITTED Allows reading of committed data. ISOLATION_REPEATABLE_READ Unless the field is modified by this transaction, the highest isolation level ISOLATION_SERIALIZABLE is fully compliant with the ACID principle, which is usually implemented by locking the table (slowest) none

  1. Transaction timeout

Given a timeout for a transaction, the transaction is automatically rolled back if the transaction has not completed by a certain time.

  1. Is it read-only?

With a read-only transaction, changes made by other transactions to the database during the execution of the transaction are transparent to the transaction, i.e. changes made by other transactions are not visible to the transaction. This is often used to ensure overall consistency of data when performing multiple queries to count information.

  1. Rollback rules

The rollback rule defines which exceptions the transaction rolls back. By default, a transaction is rolled back only when it encounters a runtime exception, not when it encounters a checking exception.

Fourth, Spring transaction management form

  1. Programmatic transaction

The use of TransactionTemplate or PlatformTransactionManager

TransactionTemplate tt = new TransactionTemplate();

tt.execute(status -> {

// Perform the operation

doSth();

// Return the operation result

return obj;

});

  1. Declarative transaction

Reference: Five ways to configure Spring transactions

Spring defines the interface of the transaction manager, which is implemented by a specific platform. Spring transactions have five attributes: transaction propagation behavior, transaction isolation level, transaction timeout, transaction read-only, and rollback rules; Propagation behaviors: required, supports, MANDATORY, required_new, not_support, never, and nested; Isolation levels: default, READ_UNcommited, READ_COMMITTED, REPEATABLE_read, serialIZABLE;