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

This article mainly explains "how to master Spring transaction management + thing isolation level". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to master Spring transaction management + thing isolation level".

Spring transaction

A transaction is a logical set of operations. The logical units that make up this set of operations must all be completed, and if one fails, the transaction rolls back to its original state as if nothing had happened.

Transactions have four characteristics: ACID

Atomicity: a transaction is an atomic operation that consists of a series of actions. The atomicity of the transaction ensures that the action is either complete or completely ineffective.

Consistency: once the transaction is completed (success or failure), the system must ensure that the business it models is in a consistent state and does not fail partially. Data in reality should not be corrupted.

Isolation: there may be many transactions that process the same data at the same time, so each transaction should be isolated from other transactions to prevent data corruption.

Durability: once the transaction is completed, no matter what system error occurs, its results should not be affected, so that it can recover from any system crash. Typically, the results of the transaction are written to persistent memory.

1 Communication behavior

The first aspect of a transaction is the propagation behavior (propagation behavior). When a transaction method is called by another transaction method, you must specify how the transaction should be propagated. For example, a method may continue to run in an existing transaction, or it may open a new transaction and run in its own transaction. Spring defines seven propagation behaviors:

Propagating behavior meaning 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 PROPAGATION_SUPPORTS will be started indicating that the current method does not require a transaction context, but if there is a current transaction, the method will run PROPAGATION_MANDATORY in the transaction indicating that the method must run in the transaction, and if the current transaction does not exist, an exception PROPAGATION_REQUIRED_NEW will be thrown indicating that the current method must run in its own transaction. A new transaction will be started. If there is a current transaction, the current transaction is suspended during the execution of the method. If you use JTATransactionManager, you need to access TransactionManagerPROPAGATION_NOT_SUPPORTED to indicate that the method should not be running in a transaction. If there is a current transaction, the current transaction is suspended while the method is running. If you use JTATransactionManager, you need to access TransactionManagerPROPAGATION_NEVER to indicate that the current method should not be running in a transaction context. If there is currently a transaction running, an exception PROPAGATION_NESTED is thrown to indicate that if a transaction already exists, the method will run in a nested transaction. Nested transactions can be committed or rolled back independently of the current transaction. If the current transaction does not exist, it behaves like PROPAGATION_REQUIRED. Note that the support of different manufacturers for this kind of communication behavior is different. You can refer to the resource manager's documentation to confirm whether they support nested transactions (the following is a colloquial explanation)

When a transaction method is called by another transaction method, you must specify how the transaction should be propagated. For example, a method may continue to run in an existing transaction, or it may open a new transaction and run in its own transaction. Spring defines seven propagation behaviors:

1 "PROPAGATION_REQUIRED supports the current transaction if there is a transaction. If there is no transaction, start a new transaction.

2 "PROPAGATION_SUPPORTS supports the current transaction if there is a transaction. If there is no transaction, the execution of the non-transaction. But for transaction managers that synchronize transactions, PROPAGATION_SUPPORTS is slightly different from not using transactions.

3 "PROPAGATION_MANDATORY supports the current transaction if a transaction already exists. If there is no active transaction, an exception is thrown.

4 "PROPAGATION_REQUIRES_NEW always opens a new transaction. If a transaction already exists, the existing transaction is suspended.

I call ts1 an outer transaction and ts2 an inner transaction. As you can see from the above code, ts2 and ts1 are two separate transactions that are not related to each other. The success of Ts2 does not depend on ts1. If the doSomeThingB method of the methodA method fails after calling the methodB method, the result of the methodB method is still submitted. The results caused by code other than methodB are rolled back. With PROPAGATION_REQUIRES_NEW, you need to use JtaTransactionManager as the transaction manager.

5 "PROPAGATION_NOT_SUPPORTED always executes non-transactionally and suspends any existing transactions. With PROPAGATION_NOT_SUPPORTED, you also need to use JtaTransactionManager as the transaction manager.

6 "PROPAGATION_NEVER is always executed non-transactionally. Indicates that the current method should not run in the context of a transaction. If a transaction is currently running, an exception is thrown. (when a transaction method is called by another transaction method) if there is an active transaction, an exception is thrown.

7 "PROPAGATION_NESTED runs in a nested transaction if an active transaction exists. If there is no active transaction, press the TransactionDefinition.PROPAGATION_REQUIRED property to execute.

This is a nested transaction and when using the JDBC 3.0 driver, only DataSourceTransactionManager is supported as the transaction manager. A JDBC-driven java.sql.Savepoint class is required.

Some transaction manager implementations of JTA may provide the same functionality. With PROPAGATION_NESTED, you also need to set the nestedTransactionAllowed property of PlatformTransactionManager to true; and the value of the nestedTransactionAllowed property to false by default.

A very important concept of nested transactions is that inner transactions depend on outer transactions. When the outer transaction fails, the actions made by the inner transaction are rolled back. The failure of the inner transaction operation does not cause the rollback of the outer transaction.

Note:

1 "the difference between PROPAGATION_NESTED and PROPAGATION_REQUIRES_NEW: they are very similar, like a nested transaction, and if there is no active transaction, a new transaction is opened." With PROPAGATION_REQUIRES_NEW, the inner transaction and the outer transaction are like two separate transactions, and once the inner transaction is committed, the outer transaction cannot be rolled back. The two transactions do not affect each other. Two transactions are not really a nested transaction. At the same time, it needs the support of JTA transaction manager.

2 "when using PROPAGATION_NESTED, the rollback of the outer transaction can cause the rollback of the inner transaction. The exception of the inner transaction does not lead to the rollback of the outer transaction, it is a real nested transaction. When DataSourceTransactionManager uses savepoint to support PROPAGATION_NESTED, drivers above JDBC 3.0 and JDK version above 1.4 are required. Other JTA TrasactionManager implementations may be supported in different ways.

PROPAGATION_REQUIRES_NEW starts a new "internal" transaction that is not dependent on the environment. This transaction will be completely commited or rolled back without relying on external transactions, it has its own isolation scope, its own locks, and so on. When the internal transaction starts execution, the external transaction will be suspended, and when the internal transaction ends, the external transaction will continue to execute.

On the other hand, PROPAGATION_NESTED starts a "nested" transaction, which is a true subtransaction of an existing transaction. When the hidden transaction starts to execute, it will get a savepoint. If this nested transaction fails, we will roll back to this savepoint. A hidden transaction is part of an external transaction, and it will not be committed until the external transaction is completed.

5 "it can be seen that the biggest difference between PROPAGATION_REQUIRES_NEW and PROPAGATION_NESTED is that PROPAGATION_REQUIRES_NEW is a completely new transaction, while PROPAGATION_NESTED is a sub-transaction of an external transaction. If an external transaction is commit, nested transactions will also be commit. This rule also applies to roll back.

6 "PROPAGATION_REQUIRED should be our first transaction propagation behavior. It can meet most of our transaction needs.

2 isolation level

The second dimension of transactions is the isolation level (isolation level). The isolation level defines the extent to which one transaction may be affected by other concurrent transactions.

Problems caused by concurrent transactions

In a typical application, multiple transactions run concurrently, often manipulating the same data to complete their respective tasks. Although concurrency is necessary, it can cause the following problems:

Dirty read (Dirty reads)-dirty reading occurs when one transaction reads data overwritten by another transaction that has not yet been committed. If the overwrite is rolled back later, the data obtained by the first transaction is invalid.

Unrepeatable reads (Nonrepeatable read)-- unrepeatable reads occur when a transaction executes the same query two or more times, but gets different data each time. This is usually because another concurrent transaction is updated during two queries.

Phantom read-Phantom reading is similar to unrepeatable reading. It occurs when one transaction (T1) reads several rows of data, and then another concurrent transaction (T2) inserts some data. In the subsequent query, the first transaction (T1) will find some additional records that do not already exist.

The difference between unrepeatable reading and phantom reading

The key point of unrepeatable reading is modification: under the same condition, the data you read, read it again and find that the value is different.

The focus of phantom reading is to add or delete: under the same conditions, the number of records read for the first time and the second time is not the same.

From the overall results, it seems that both unrepeatable reading and phantom reading show that the results of the two reads are inconsistent. But if you look at it from a control point of view, there is a big difference between the two. For the former, only the records that meet the conditions need to be locked. For the latter, lock records that meet the conditions and their proximity.

The meaning of isolation level ISOLATION_DEFAULT uses the default isolation level of the back-end database, the lowest isolation level of ISOLATION_READ_UNCOMMITTED, which allows you to read data changes that have not yet been committed, which may lead to dirty, phantom or non-repeatable readings. ISOLATION_READ_COMMITTED allows you to read data that has been committed by concurrent transactions, and can prevent dirty reads. However, it is still possible for phantom reading or non-repeatable reading to occur. ISOLATION_REPEATABLE_READ 's multiple reads of the same field are consistent, unless the data is modified by its own transaction, which can prevent dirty reading and non-repeatable reading, but phantom reading may still occur at the highest isolation level of ISOLATION_SERIALIZABLE, which is fully subject to the isolation level of ACID, ensuring that dirty reading, non-repeatable reading and phantom reading are prevented, and that it is also the slowest transaction isolation level. Because it is usually achieved by completely locking the database table related to the transaction, some explanations for the above table are as follows:

1 "ISOLATION_DEFAULT uses the default isolation level of the back-end database. (ISOLATION [/ / a / s / le / n] isolation)

2 "minimum isolation level of ISOLATION_READ_UNCOMMITTED, which allows reading of uncommitted data changes, which may result in dirty, phantom, or unrepeatable reads."

3 "ISOLATION_READ_COMMITTED allows you to read data that has been committed by concurrent transactions, which prevents dirty reads, but phantom or unrepeatable reads can still occur. Dirty read: occurs when one transaction reads and another rewrites data that has not yet been committed to the database. Because the overwrite is not committed to the database, it may be rolled back. Causes the value read by the first transaction to be invalid)

4 "ISOLATION_REPEATABLE_READ multiple reads to the same field in a transaction are consistent unless the data is modified by the transaction itself. Dirty and unrepeatable readings can be prevented, but phantom readings can still occur (non-repeatable: when the same query is executed multiple times in a transaction, the values are different, with emphasis on modifying update)

5 "ISOLATION_SERIALIZABLE 's highest isolation level is fully compliant with ACID's isolation level, ensuring that dirty, unrepeatable, and phantom reads are prevented, and the slowest transaction isolation level, as it is usually achieved by fully locking the database tables associated with the transaction. Illusion: in a transaction, when you execute the same query two or more times, you get a different number of rows of results. Focus on adding insert and deleting delete)

3 read only

The third feature of a transaction is whether it is a read-only transaction. If the transaction only does this to the back-end database, the database can take advantage of the read-only nature of the transaction to make some specific optimizations. By making the transaction read-only, you can give the database a chance to apply the optimizations it deems appropriate.

4 transaction timeout

In order for the application to run well, the transaction cannot run for too long. Because transactions may involve locking to the back-end database, long-term transactions can unnecessarily consume database resources. A transaction timeout is a timer for a transaction, and if the transaction does not finish execution within a certain period of time, it will be automatically rolled back instead of waiting for it to end.

5 rollback rules

The last aspect of the transaction Pentagon is a set of rules that define which exceptions cause the transaction to roll back and which do not. By default, a transaction rolls back only if it encounters a run-time exception, but it does not roll back when it encounters a check-type exception (this behavior is consistent with EJB's rollback behavior), but you can declare that a transaction is rolled back like a run-time exception when it encounters a specific check-type exception. Similarly, you can declare that a transaction does not roll back when it encounters specific exceptions, even if those exceptions are run-time exceptions.

Programmatic transaction

Spring provides support for programmatic and declarative transactions. Programmatic transactions allow users to precisely define the boundaries of transactions in code, while declarative transactions (based on AOP) help users decouple actions from transaction rules.

To put it simply, programmatic transactions invade the business code, but provide more detailed transaction management; while declarative transactions, based on AOP, can not only play the role of transaction management, but also do not affect the specific implementation of the business code. Programmatic transactions are put into the code. Declarative transactions are placed in AOP)

Thank you for your reading, the above is the content of "how to master Spring transaction management + thing isolation level". After the study of this article, I believe you have a deeper understanding of how to master Spring transaction management + thing isolation level, 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.