Propagation properties and transaction isolation level of transactions in spring

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.   Dirty reads non-repeatable reads phantom reads Serializable Won't Won't Won't REPEATABLE READ Won't Won't meeting READ COMMITTED Won't meeting meeting Read Uncommitted meeting meeting meeting   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.  Among the four isolation levels, Serializable has the highest level and Read Uncommited the lowest level.  The default isolation level of most databases is: Read Commited , such as Sql Server , Oracle.  The default isolation level of a few databases is Repeatable Read, such as the MySQL InnoDB storage engine  even at the lowest level, the first type of lost update problem will not occur.   1.  Dirty read (transactions are not committed, read ahead of time) fetch)  : Dirty read refers to when a transaction is accessing data and modifying 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. 2.  Non-repeatable read (inconsistency between two reads)  : 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 the 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. For example, an editor reads the same document twice, but between reads, the author rewrites the document. When editors read the document a second time, the document has changed. Raw reads are not repeatable. This problem can be avoided if editors can only read the document after the author has all finished writing.  3.  Phantom 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. For example, an editor makes changes to a document submitted by an author, but when the production department merges their changes into the master copy of the document, it finds that the author has added unedited new material to the document. This problem can be avoided if no one can add new material to the document until the editorial staff and the production department have finished working on the original document.  4.  The first type of update loss (rollback loss)  :    When two transactions update the same data source, if the first transaction is committed and the other transaction is revoked, it will be followed by the first transaction. New was also withdrawn. That is to say, the update done by the first transaction is lost.  5.  The second type of update loss (coverage loss)  :    The second type of update loss is a concurrency problem often encountered in practical applications. It is essentially the same type of concurrency problem as non-repeatable read, and it is usually regarded as non-repeatable read. Special case: A second type of lost update occurs when two or more transactions query the same record and then each update the row based on the original query result. Because each transaction is unaware of the existence of other transactions, the changes made to the record by the last transaction will overwrite the committed updates made to the record by other transactions...  Additional: Spring declarative transactions based on metadata:  The Isolation property supports a total of five transaction settings, which are described as follows:  l DEFAULT uses the isolation level (default) set by the database, and the isolation level is determined by the default setting of the DBA.  l READ_UNCOMMITTED will cause dirty reads, non-repeatable reads, and phantom reads (lowest isolation level and high concurrent performance)  l READ_COMMITTED will cause non-repeatable reads and phantom reads (locking the row being read)  l REPEATABLE_READ will cause phantom reads (locking all All rows read)  l SERIALIZABLE ensures that all situations will not happen (lock table)  The point of non-repeatable reading is to modify:  the same conditions, the data you have read, read it again and find that the value is different.  Phantom read The point is to add or delete  the same conditions, the number of records read out the first time and the second time are different