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. 1: PROPAGATION_REQUIRED Join the current transaction to be executed is not in another transaction, then start a new transaction For example, if the transaction level of ServiceB.methodB is defined as PROPAGATION_REQUIRED, then when ServiceA.methodA is executed, ServiceA.methodA has already started a transaction. At this time, ServiceB.methodB is called. ServiceB.methodB sees that it is already running in ServiceA.methodA Inside the transaction, no new transaction will be started. 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 ServiceB.methodB's transaction has been Submit, but ServiceA.methodA will be rolled back next fail, and ServiceB.methodB will also be rolled back 2: PROPAGATION_SUPPORTS If it is currently in a transaction, that is, it is running in the form of a transaction. If it is not currently in a transaction, it is running in a non-transactional form. 3: PROPAGATION_MANDATORY Must run within 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 rather convoluted. 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 be suspended, ServiceB.methodB will start a new transaction, and after the transaction of ServiceB.methodB is completed, He just continued. 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 is two different transactions. If ServiceB.methodB has been submitted, then ServiceA.methodA fails and rolls back, but ServiceB.methodB will not roll back. Rollback if ServiceB.methodB fails, 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, while 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 the transaction of ServiceA.methodA. 6: PROPAGATION_NEVER Cannot run in 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 the savepoint. The difference between him and PROPAGATION_REQUIRES_NEW is that PROPAGATION_REQUIRES_NEW starts another transaction, which will be independent of its parent transaction. The Nested 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 to say, if ServiceB.methodB fails to roll back, then ServiceA.methodA will also roll back to the savepoint point. ServiceA.methodA can choose another branch, such as ServiceC.methodC, continue to execute, to try to complete its own transaction. But this transaction is not defined in the EJB standard. 2. Isolation Level (transaction isolation level): 1. Serializable: The most stringent level, transactions are executed serially, and resource consumption is the largest; 2. REPEATABLE READ: It is guaranteed that a transaction will not modify data that has been read by another transaction but not committed (rolled back). The "dirty reads" and "non-repeatable reads" situations are avoided, but with more performance penalty. 3. READ COMMITTED: The default transaction level of most mainstream databases, which ensures that a transaction will not read data that has been modified but not committed by another parallel transaction, avoiding "dirty reads". This level is suitable for most systems. 4. Read Uncommitted: It ensures that no illegal data will be read during the reading process. The isolation level is to deal with the concurrency of multiple transactions. We know that parallelism can improve the throughput and efficiency of the database, but not all concurrent transactions can run concurrently, which requires checking the serializability conditions of database textbooks. It is not explained here. Let's start by saying 3 unflattering things that can happen in concurrency 1: Dirty reads--read dirty data. That is to say, for example, the uncommitted (still cached) data of transaction A is read by transaction B. If transaction A fails and rolls back, the data read by transaction B will be wrong. 2: non-repeatable reads--data cannot be read repeatedly. For example, in transaction A, the value of data -total- is read in two places. In the first reading, the total was 100, then transaction B changed the total data to 200, and transaction A read it again, and found that the total turned out to be 200, causing transaction A data confusion. 3: phantom reads--phantom read data, this is similar to non-repeatable reads, and it is also a problem of inconsistency of multiple reads in the same transaction. However, the inconsistency of non-repeatable reads is because the data set he wants to fetch has been changed (such as total data), but the inconsistency of the data to be read by phantom reads is not the change in the data set he wants to read, but his conditional data. set changes. For example, Select account.id where account.name="ppgogo*", read 6 qualified ids for the first time, and when read the second time, due to transaction b, the name of an account was changed from "dd" to "ppgogo1", the result is 7 data.
3. readOnly The readOnly flag in the 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). 4. Timeout There is also the option to define a "timeout" value in the transaction properties, specifying a transaction timeout in seconds. In JTA this would simply be passed to the J2EE server's transaction coordinator and interpreted accordingly
20110112 The database provides four transaction isolation levels, and different isolation levels are implemented by different lock classes. |
Propagation properties and transaction isolation level of transactions in spring
Guess you like
Origin http://43.154.161.224:23101/article/api/json?id=325979217&siteId=291194637
Recommended
Ranking