1. Propagation (propagation properties of transactions)
Propagation : The key property determines which method the proxy should add transactional behavior to. The most important part of such a property is the propagation behavior. The following options are available: PROPAGATION_REQUIRED--support the current transaction, if there is no current transaction, create a new transaction. This is the most common choice.
PROPAGATION_SUPPORTS--Support the current transaction, if there is no current transaction, it will be executed in a non-transactional manner.
PROPAGATION_MANDATORY--Supports the current transaction, if there is no current transaction, an exception is thrown.
PROPAGATION_REQUIRES_NEW--Create a new transaction, if there is a current transaction, suspend the current transaction.
PROPAGATION_NOT_SUPPORTED--Perform the operation in a non-transactional manner, suspending the current transaction if there is a current transaction.
PROPAGATION_NEVER--Execute in a non-transactional manner, throwing an exception if there is currently a transaction.
Let's first look at spring 's transaction propagation behavior types
| Transaction propagation behavior type |
illustrate |
| PROPAGATION_REQUIRED |
If there is no current transaction, create a new transaction, if there is already a transaction, join the transaction. This is the most common choice. |
| PROPAGATION_SUPPORTS |
Support the current transaction, if there is no current transaction, it will be executed in a non-transactional mode. |
| PROPAGATION_MANDATORY |
Use the current transaction, or throw an exception if there is no current transaction. |
| PROPAGATION_REQUIRES_NEW |
Create a new transaction. If there is a current transaction, suspend the current transaction. |
| PROPAGATION_NOT_SUPPORTED |
Execute the operation in a non-transactional manner, suspending the current transaction if there is a current transaction. |
| PROPAGATION_NEVER |
Executes non-transactionally and throws an exception if a transaction currently exists. |
| PROPAGATION_NESTED |
If a transaction currently exists, execute within a nested transaction. If there are no current transactions, do something similar to PROPAGATION_REQUIRED . |
When using PROPAGATION_NESTED , the underlying data source must be based on JDBC 3.0 , and the implementer needs to support the savepoint transaction mechanism.
The readOnly flag in the readOnly
transaction attribute indicates that the corresponding transaction should be optimized as a read-only transaction. This is an optimization tip . In some cases, some transaction strategies can have a significant optimization effect, such as avoiding dirty checking (trying to "refresh") when using Object/Relational mapping tools (eg: hibernate or TopLink).
1: PROPAGATION_REQUIRED
joins the transaction currently being executed is not in another transaction, then start a new transaction
. For example, the transaction level of ServiceB.methodB is defined as PROPAGATION_REQUIRED, then when ServiceA.methodA is executed,
ServiceA.methodA has already started After the transaction is completed, ServiceB.methodB is called at this time. ServiceB.methodB sees that it is already running inside
the transaction of ServiceA.methodA, so it will not start a new transaction. And if ServiceA.methodA runs and finds that he is not in a transaction, he will assign himself a transaction.
This way, if an exception occurs in ServiceA.methodA or anywhere within ServiceB.methodB, the transaction will be rolled back. Even if the transaction of ServiceB.methodB has been
committed, but ServiceA.methodA will be rolled back in the next fail, ServiceB.methodB will also be rolled back
2: PROPAGATION_SUPPORTS
If it is currently in a transaction, that is, it runs in the form of a transaction. If it is no longer in a transaction, it runs in a non-transactional form.
3: PROPAGATION_MANDATORY
must be run in a transaction. That is, he can only be called by a parent transaction. Otherwise, he will throw an exception
4: PROPAGATION_REQUIRES_NEW
This is a bit of a twist. For example, we design the transaction level of ServiceA.methodA to be PROPAGATION_REQUIRED, and the transaction level of ServiceB.methodB to be PROPAGATION_REQUIRES_NEW,
then when ServiceB.methodB is executed, the transaction where ServiceA.methodA is located will hang, and ServiceB.methodB will start a new one Transaction, waits for ServiceB.methodB's transaction to complete before
he continues to execute. The difference between him and the PROPAGATION_REQUIRED transaction is the degree of rollback of the transaction. Because ServiceB.methodB is a new transaction, then there are
two different transactions. If ServiceB.methodB has been submitted, then ServiceA.methodA fails and rolls back, but ServiceB.methodB will not roll back. If ServiceB.methodB fails and rolls back,
if the exception he throws is caught by ServiceA.methodA, the ServiceA.methodA transaction may still commit.
5: PROPAGATION_NOT_SUPPORTED
Transactions are not currently supported. For example, the transaction level of ServiceA.methodA is PROPAGATION_REQUIRED, and the transaction level of ServiceB.methodB is PROPAGATION_NOT_SUPPORTED,
then when ServiceB.methodB is executed, the transaction of ServiceA.methodA is suspended, and he finishes running in a non-transactional state, and then continues ServiceA .methodA's transaction.
6: PROPAGATION_NEVER
cannot run within a transaction. Assuming that the transaction level of ServiceA.methodA is PROPAGATION_REQUIRED, and the transaction level of ServiceB.methodB is PROPAGATION_NEVER,
then ServiceB.methodB will throw an exception.
7: PROPAGATION_NESTED
The key to understanding Nested is savepoint. The difference between him and PROPAGATION_REQUIRES_NEW is that PROPAGATION_REQUIRES_NEW starts another transaction, which will be independent of his parent transaction,
while Nested's transaction is dependent on his parent transaction, and his submission is to be submitted together with his parent transaction. . That is, if the parent transaction rolls back last, he will also roll back.
And the nice thing about Nested affairs is that he has a savepoint.
****************************************
ServiceA {
/**
* The transaction property is configured as PROPAGATION_REQUIRED
*/
void methodA() {
try {
//savepoint
ServiceB.methodB(); //PROPAGATION_NESTED level
} catch (SomeException) {
// Execute other business, such as ServiceC.methodC();
}
}
}
********************************************
That is ServiceB. If methodB fails and rolls back, then ServiceA.methodA will also roll back to the savepoint point. ServiceA.methodA can choose another branch, such as
ServiceC.methodC, to continue to execute to try to complete its own transaction.
But this transaction is not defined in the EJB standard.
- 6. Transaction isolation level in spring
- The transaction isolation level of spring is actually an encapsulation of the four transaction isolation levels of the SQL92 standard. For details, please participate in my blog post: http://kingj.iteye.com/admin/blogs/1675011
- The transaction isolation level of spring is shown in the following table
-
isolation level meaning ISOLATION_DEFAULT Use the database's default transaction isolation level ISOLATION_READ_UNCOMMITTED Allows reading of uncommitted changes, which can lead to dirty reads, phantom reads, and non-repeatable reads ISOLATION_READ_COMMITTED Allows reading from committed transactions, preventing dirty reads, but phantom reads and non-repeatable reads are still possible ISOLATION_REPEATABLE_READ The results of multiple reads on the same field are consistent, unless the data is modified spontaneously by the current transaction. Dirty reads and non-repeatable reads can be prevented, but phantom reads can still occur ISOLATION_SERIALIZABLE Fully obey the ACID isolation principle to ensure that dirty reads, non-repeatable reads, and phantom reads do not occur, but the execution efficiency is the lowest.
Spring事务的隔离级别
1. ISOLATION_DEFAULT： 这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别.
另外四个与JDBC的隔离级别相对应
2. ISOLATION_READ_UNCOMMITTED： 这是事务最低的隔离级别，它充许令外一个事务可以看到这个事务未提交的数据。
这种隔离级别会产生脏读，不可重复读和幻像读。
3. ISOLATION_READ_COMMITTED： 保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据
4. ISOLATION_REPEATABLE_READ： 这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。
它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。
5. ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。
除了防止脏读，不可重复读外，还避免了幻像读。
What is dirty data, dirty read, non-repeatable read, phantom read?
Dirty read: Refers to when a transaction is accessing data and making modifications to the data, and the modification has not been submitted to the database, at this time,
another transaction also accesses the data and then uses the data. Because this data is uncommitted data, the data read by
another transaction is dirty data, and operations based on dirty data may be incorrect.
Non-repeatable read: Refers to reading the same data multiple times within a transaction. While this transaction is not over, another transaction also accesses the same data.
Then, between two reads of data in the first transaction, due to the modification of the second transaction, the data read twice by the first transaction
may be different. In this way, the data read twice in a transaction is different, so it is called non-repeatable read.
Illusionary reading: Refers to a phenomenon that occurs when transactions are not executed independently, for example, the first transaction modifies data in a table, and this modification involves
all data rows in the table. At the same time, the second transaction also modifies the data in this table by inserting a new row of data into the table. Then,
it will happen later that the user who operates the first transaction finds that there are no modified data rows in the table, as if a hallucination occurred.