Hello, today I share Spring affairs with you. Please take out your notebook and write it down.

The Spring framework provides a unified transaction abstraction through a unified programming model that makes it easy for applications to switch between different transaction frameworks.

Before learning about Spring transactions, let’s take a quick look at database transactions.

Introduction to Database Transactions

The set of operations that make up a single logical unit of work is called a transaction. Even if there is a failure, the database system must ensure that the transaction executes correctly — either the entire transaction or none of the operations belonging to that transaction. In the case of a money transfer, you should ensure that the amount paid out of a checking account and the amount deposited into a savings account are done in the same logical unit of work. In short, a transaction is a program execution unit that accesses and possibly updates various data items.

Characteristics of transactions

The database needs to maintain the following four properties of transactions:

An Atomicity transaction is an atomic operation consisting of a series of actions. The atomicity of the transaction ensures that this sequence of actions either completes completely or does not work at all.

2. Consistency Isolation Maintains the consistent database state of the database during the execution of transactions (in the absence of concurrent transactions).

3. Isolation There is no impact between the execution of concurrent transactions. Operations within one transaction have no impact on other transactions, which requires the transaction Isolation level to specify Isolation. Each transaction does not feel that other transactions in the system are executing concurrently.

Once a transaction completes, database changes must be permanent, even if system failures occur.

The isolation level of the transaction

In practical applications, the data in the database is accessed by multiple users. When multiple users operate the same data at the same time, some transaction concurrency problems may occur:

1. Dirty reads. A transaction reads uncommitted data from another transaction.

2. Non-repeatable Read. A transaction reads the same row twice, but gets different results.

3. Phantom Read A transaction executes two queries, but the results of the second query contain data not present in the first query.

4. Lost Updates. The lost update can be divided into two types, namely, the first type of lost update and the second type of lost update. The first type of lost update refers to that when two transactions operate on the same data at the same time, when the first transaction is cancelled, the updated data of the second transaction is overwritten, and the second transaction causes data loss. The second type of lost update refers to that when two transactions operate on the same data at the same time, the first transaction overwrites the modification result submitted by the second transaction after successfully submitting the modification result, causing data loss to the second transaction.

In order to avoid the above transaction concurrency problem, there are four transaction isolation levels defined in the standard SQL specification. Each isolation level can handle transactions differently:

1.Serializable

Provide strict transaction isolation. It requires serialized execution of transactions, which can only be executed one after another, not concurrently. This isolation level effectively prevents dirty reads, unrepeatable reads, and phantom reads. However, this level can cause a lot of timeouts and lock contention and is rarely used in practice.

Repeatable Read (Repeatable Read)

During execution, a transaction can access newly inserted data successfully committed by other transactions, but cannot access successfully modified data. A transaction that reads data will prohibit a write transaction (but allow a read transaction), and a write transaction will prohibit any other transaction. This isolation level effectively prevents unrepeatable and dirty reads.

21. admitted to Read

During execution, a transaction can access both newly inserted data successfully committed by other transactions and successfully modified data. A transaction reading data allows other transactions to continue to access the row, but an uncommitted write transaction prevents other transactions from accessing the row. This isolation level effectively prevents dirty reads.

4.Uncommitted Read

During execution, a transaction can access both newly inserted data that has not been committed by other transactions and modified data that has not been committed. If one transaction has already started writing data, another transaction is not allowed to write data at the same time, but other transactions are allowed to read this row. This isolation level prevents lost updates.

All of the above isolation levels do not allow Dirty Write.

Generally speaking, the higher the isolation level of a transaction, the more integrity and consistency of the database is guaranteed, but relatively speaking, the higher the isolation level, the greater the impact on concurrency performance. For this reason, the default isolation level of a database is usually set to Committed Read, which protects against dirty reads while providing good concurrency performance. Although this level of isolation can lead to concurrent problems such as unrepeatable reads, phantom reads, and type ii lost updates, it can be controlled by using pessimistic or optimistic locks in your application.

The Spring transaction

The essence of Spring transactions is the support of the database for transactions, using JDBC transaction management mechanism, using java.sql.Connection object to complete the submission of transactions, before the use of Spring framework, Java transaction implementation example code is as follows:

​

Spring framework provides a unified transaction abstraction, whether JTA, JDBC, Hibernate/JPA, Mybatis/Mybatis-Plus, Spring uses a unified programming model, making it easy for applications to switch between different transaction frameworks. This is also consistent with the idea of interface oriented programming. Spring framework of transaction code in the org. Springframework: Spring – tx. The core class diagram for Spring transaction abstraction is as follows:

Spring is the core of the transaction management interface PlatformTransactionManager. The behavior of the interface definition PlatformTransactionManager transactions, PlatformTransactionManager TransactionDefinition and TransactionStatus interface. The TransactionDefinition interface defines spring-compatible transaction properties (such as isolation level, transaction propagation behavior, and so on). The TransactionStatus interface defines the status of the transaction (such as whether to roll back, complete, include Save points, flush the underlying session to the data store (if applicable), and so on).

Introduction of PlatformTransactionManager

PlatformTransactionManager is the core of the Spring transaction framework interface. Applications can use PlatformTransactionManager directly, but it is not mainly used for API: the application will use Transaction template (TransactionTemplate) or Declarative Transaction (Declarative Transaction).

For the need to implement PlatformTransactionManager interface application, can be realized through the way of inheritance AbstractPlatformTransactionManager abstract classes. AbstractPlatformTransactionManager transaction propagation behavior and transaction has realized synchronous processing. Subclasses need to implement template methods for transaction-specific states such as BEGIN, suspend, Resume, commit. Spring has achieved JtaTransactionManager transaction framework (JPA) and DataSourceTransactionManager (JDBC). An application can implement a transaction manager by referring to the above methods. PlatformTransactionManager transaction inheritance example is as follows:

Spring transaction isolation level and propagation level

Spring transaction isolation level and Spring transaction propagation level are defined in the TransactionDefinition interface. The isolation level mainly controls the degree of isolation when transactions are accessed concurrently. Spring supports the following isolation levels:

The remaining four isolation levels are consistent with the isolation levels of the database specification, except for the use of ISOLATION_DEFAULT to indicate that the default isolation level of the database is used.

It is important to note that higher isolation levels mean poorer performance for concurrent execution of database transactions. Although the JDBC specification defines the above behavior for transaction support, the degree of support for transactions may vary from JDBC driver to database vendor. We generally set the READ_COMMITTED level for performance reasons. Dirty reads that cannot be avoided at the READ_COMMITTED isolation level are typically handled using database locks.

The propagation level mainly controls how Spring handles transactions when a transaction method is called (for example, when one transaction method calls another). There are seven classes of Spring transaction propagation levels. They are:

(1)PROPAGATION_REQUIRED: Supports the current transaction, add it if there is one, or create a new one if there is none. This mode is the default transaction propagation mode.

(2)PROPAGATION_SUPPORTS: Supports the current transaction, PROPAGATION_SUPPORTS if a transaction currently exists, or non-transactionally if no transaction currently exists.

(3)PROPAGATION_MANDATORY: The current transaction is supported, PROPAGATION_MANDATORY if a transaction exists, and an exception is thrown if no transaction exists. (Transaction must be present)

(4)PROPAGATION_REQUIRES_NEW: Support the current transaction, suspend the current transaction if there is one, and create a new one, or create one yourself if there is no transaction.

5)Propagation_NOT_SUPPORTED: No transaction is supported, suspend the current transaction if one exists, and resume the transaction after execution (ignoring the current transaction).

(6)PROPAGATION_NEVER: No transaction is supported, PROPAGATION_NEVER: Throws an exception if a transaction exists. (There must be no transaction currently)

(7)PROPAGATION_NESTED: If a transaction exists, it is nested in the current transaction. If there is no transaction, create a new transaction to execute itself. For nested transactions, the rollback of the internal transaction does not affect the commit of the external transaction; But the external transaction rollback rolls back the internal transaction as well. (The difference between this and creating a transaction)

Well, that’s all for today’s article, hoping to help those of you who are confused in front of the screen