Shulou(Shulou.com)06/03 Report--

This article mainly explains "how to understand Spring transactions". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's ideas to study and learn "how to understand Spring transactions".

Brief introduction of database transaction

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 is executed correctly-either the entire transaction is executed, or none of the operations belonging to the transaction are performed. Taking the transfer of funds as an example, we should ensure that the operation of the expenditure amount of the checking account and the deposit amount of the savings account are completed in the same logical unit of work. In short, a transaction is a program execution unit (unit) that accesses and possibly updates various data items.

Characteristics of transactions

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

1. An Atomicity transaction is an atomic operation that consists of a series of actions. The atomicity of the transaction ensures that this series of actions are either completed or completely ineffective.

two。 Consistency isolates the consistent database state of the database when executing transactions (when no other transactions are concurrent).

3. Isolation) there is no impact between concurrent transaction execution, and 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.

4. Durability) once a transaction is completed, changes to the database must be permanent, even in the event of a system failure.

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, there may be some transaction concurrency problems:

1. Dirty reading (Dirty Read). One transaction reads uncommitted data from another transaction.

two。 Cannot be read repeatedly (Non-repeatable Read). A transaction repeatedly reads the same row of data twice, but gets different results.

3. False reading / illusory reading (Phantom Read). A transaction executes a query twice, but the result of the second query contains data that does not appear in the first query.

4. Missing update (Lost Update). Lost updates can be divided into two categories, namely, the first type of lost updates and the second type of lost updates. The first kind of missing update means that when two transactions operate on the same data at the same time, when the first transaction is undone, the updated data of the committed second transaction is overwritten, and the second transaction results in data loss. The second kind of missing update means that when two transactions operate the same data at the same time, after the first transaction successfully commits the modification result, it overwrites the modification result that has been committed by the second transaction, resulting in data loss to the second transaction.

In order to avoid the above transaction concurrency problems, four transaction isolation levels are defined in the standard SQL specification, and different isolation levels handle transactions differently:

1.Serializable (serializable)

Provide strict transaction isolation. It requires transaction serialization execution, and transactions can only be executed one by one, not concurrently. This isolation level can effectively prevent dirty reading, non-repeatable reading and phantom reading. However, this level may lead to a large number of timeouts and lock competition, which is rarely used in practical applications.

2.Repeatable Read (repeatable)

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

3.Committed Read (read submitted)

During the execution of a transaction, you can access not only the newly inserted data successfully committed by other transactions, but also the successfully modified data. Transactions that read data allow other transactions to continue to access the row's data, but uncommitted write transactions will prevent other transactions from accessing the row. This isolation level can effectively prevent dirty reading.

4.Uncommitted Read (read not submitted)

During the execution of a transaction, you can access not only newly inserted data that has not been committed by other transactions, but also uncommitted modified data. If one transaction has already started writing data, the other transaction does not allow simultaneous write operations, but allows other transactions to read this row of data. This isolation level prevents the loss of updates.

None of the above isolation levels allow dirty writing (Dirty Write).

In general, the higher the isolation level of the transaction, the more you can ensure the integrity and consistency of the database, but relatively speaking, the higher the isolation level, the greater the impact on concurrency performance. Therefore, the default isolation level of the database is usually set to committed read (Committed Read), which not only prevents dirty reads, but also has better concurrency performance. Although this isolation level can lead to concurrency problems such as unrepeatable reads, phantom reads, and lost updates of the second type, it can be controlled by using pessimistic or optimistic locks in the application.

Spring transaction

The essence of Spring transaction is that the database supports transactions. The transaction management mechanism of JDBC is used to commit the transaction using java.sql.Connection object. Before using Spring framework, the sample code of transaction implementation in Java is as follows:

The Spring framework provides a unified transaction abstraction, and JTA, JDBC, Hibernate/JPA and Mybatis/Mybatis-Plus,Spring all use a unified programming model, which makes it easy for applications to switch between different transaction frameworks. This is also in line with the idea of interface-oriented programming. The code for the Spring transaction framework is in org.springframework:spring-tx. The core class diagram of Spring transaction abstraction is as follows:

The core interface of Spring transaction management is PlatformTransactionManager. Interface PlatformTransactionManager defines the behavior of transaction operations, and PlatformTransactionManager relies on TransactionDefinition and TransactionStatus interfaces. The TransactionDefinition interface defines Spring-compatible transaction attributes (such as isolation level, transaction propagation behavior, and so on). The TransactionStatus interface defines the state of the transaction (such as whether to roll back, complete, include a security point (Save Point), refresh the underlying session to the datastore, if applicable, and so on.

Introduction to PlatformTransactionManager

PlatformTransactionManager is the core interface of the Spring transaction framework. Applications can use PlatformTransactionManager directly, but it is not primarily for API: applications will rely on transaction templates (TransactionTemplate) or declarative transactions (Declarative Transaction).

Applications that need to implement the PlatformTransactionManager interface can be implemented by inheriting AbstractPlatformTransactionManager abstract classes. The AbstractPlatformTransactionManager class has implemented transaction propagation behavior and transaction synchronization. Subclasses need to implement template methods for transaction-specific states such as begin,suspend,resume,commit. The Spring transaction framework has implemented JtaTransactionManager (JPA) and DataSourceTransactionManager (JDBC). The application can refer to the above method to implement the transaction manager. An example of PlatformTransactionManager transaction inheritance is as follows:

Spring transaction isolation level and propagation level

The 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. The isolation levels supported by Spring are as follows:

Except for using ISOLATION_DEFAULT to indicate that the default isolation level of the database is used, the other four isolation levels are consistent with the isolation level of the database specification.

It is important to note that the higher the isolation level, the worse the concurrent execution performance of database transactions. Although the JDBC specification defines the above behaviors supported by transactions, the degree of support for transactions may vary from JDBC driver to database vendor. We generally set the READ_COMMITTED level for performance reasons. For dirty reads that cannot be avoided at the READ_COMMITTED isolation level, database locks are usually used.

The propagation level mainly controls how Spring handles transactions when calls containing transactional methods, such as one transactional method calling another transactional method, are made. There are seven types of Spring transaction propagation levels. They are:

(1) PROPAGATION_REQUIRED: support the current transaction, join if there is a current transaction, and create a new one if there is no current transaction. This is the default way of transaction propagation.

(2) PROPAGATION_SUPPORTS: supports the current transaction, joins if there is a transaction, and executes in a non-transactional manner if there is no transaction.

(3) PROPAGATION_MANDATORY: supports the current transaction, joins if there is a transaction, and throws an exception if there is no transaction. (currently there must be a transaction)

(4) PROPAGATION_REQUIRES_NEW: support the current transaction, suspend the current transaction if there is a current transaction, then create a new transaction, and create a transaction if there is no current transaction.

(5) Propagation_NOT_SUPPORTED: the current transaction is not supported. If there is a current transaction, suspend the current transaction, and resume the transaction after execution (ignore the current transaction).

(6) PROPAGATION_NEVER: the current transaction is not supported. If a transaction exists, an exception is thrown. (there must be no transactions at this time)

(7) PROPAGATION_NESTED: if there is a current transaction, it is nested within the current transaction. If there is no current transaction, create a new transaction to execute on its own. For nested transactions, the internal transaction rollback does not affect the commit of the external transaction; but the external transaction rollback rolls back the internal transaction together. (the difference between this and creating a new transaction)

Well, that's all for today's article. I hope it can help you who are confused in front of the screen.

Thank you for your reading, the above is the content of "how to understand Spring transactions". After the study of this article, I believe you have a deeper understanding of how to understand Spring transactions, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.