Spring Transaction Properties

This article describes the 5 properties of spring transactions

In spring, declaring a transaction is defined by a transaction property. Transaction properties describe how a transaction policy is applied to a method on a transaction property that contains 5 aspects:

• Propagation behavior
• Isolation level
• Rolling back rules
• Transaction timeout
• is read-only

Propagation behavior

The propagation behavior defines the transaction boundary between the client and the called method, that is, the propagation rule answers the question whether the new transaction should be started or suspended, or if the method is to run in a transactional environment. 7 Propagation Rules:

1. Propagation_mandatory (Forced propagation): Indicates that the method must run in a transaction and throws an exception if the current transaction does not exist
2. propagation_nested (nested propagation): Indicates that if a transaction is present, the method will run back into the nested transaction, and the nested transaction can be individually committed or rolled back independently of the current transaction, and if the current transaction does not exist, its behavior is propagation_ Like required.
3. Propagation_never: (Never propagated): Indicates that the current method should not run in a transactional context and throws an exception if a transaction is running
4. Propagation_not_suppored (propagation not supported): Indicates that the method should not run in a transaction, and if there is a current transaction, the current transaction will be suspended while the method is running
5. Propagation_required (Necessary propagation): Indicates that the current transaction must be running in a transaction, and if the current transaction exists, the method will run in that transaction, or a new transaction will be started
6. Propagation_required_new (new necessary propagation): Indicates that the current method must be running in its own transaction (running in a new transaction), and if the current transaction is present, the current transaction hangs
7. Propagation_support (Support Transaction): Indicates that the current method does not require a transaction context, but if there is a current transaction, the House will run in this transaction

Isolation sector

The isolation level defines the degree to which a transaction may be affected by other concurrent transactions.

Multiple concurrent transactions can cause problems:

1. Dirty Read---Dirty reads occur when a transaction is missing the ice. When a transaction overwrites but has not yet committed data, if the overwrite is rolled back later, the data obtained by the first transaction is invalid.
2. Non-REPEATABLE READ---Non-repeatable reads occur when a transaction executes the same query two or more times or more than two times, but each time a different data is obtained, this is usually because another concurrent transaction updated the data during the two queries.
3. Phantom Read---The Phantom read occurs when a transaction reads a few rows of data, and then another transaction inserts some data, and in subsequent queries, the first format finds more records that do not already exist.

Quarantine rules:

1. Isolation_default: Using default rules for back-end databases
2. Isolation_read_uncommitted: Allows reading of data changes that have not yet been committed and may result in dirty reads, Phantom reads, or non-repeatable reads
3. Isolation_read_committed: Allows reading of data that has been committed by concurrent transactions to prevent dirty reads, but phantom or non-repeatable reads can still occur
4. Isolation_repeatable_read: The multiple read results of the consent field are consistent unless the data is modified by the transaction itself to prevent dirty reads and non-repeatable reads, but Phantom reads can still occur
5. Isolatiom_serializable: Full compliance with acid isolation levels, ensuring that dirty reads are blocked, non-repeatable reads, and Phantom reads, which is the slowest level of data isolation

is read-only

If a transaction only reads to the back-end database, the database can use the transaction ID read-only feature for some specific optimizations. By setting the transaction to read-only, you can give the database an opportunity to apply the optimizations it deems appropriate. Because read-only is implemented by the database when the transaction is started, only the propagation behavior that is possible to initiate a new transaction (Propagation_required,propagation_required_new,propagation_ NESTED) method, only makes sense.

Transaction timeout

In order for the application to run well, the transaction cannot run for a long time. Because the time-out clock starts at the start of the transaction, only the methods that have the propagation behavior (propagation_required,propagation_required_new,propagation_nested) that are likely to start a new transaction , only makes sense.

　　

Transaction rollback

A transaction rollback rule defines which exceptions cause transactions to be rolled back and which do not. By default, transactions are rolled back only when they encounter a run-time exception, and are not rolled back when they encounter a check-type exception.

Specifically, look at the XML configuration

<Tx:annotation-driven/> <Tx:adviceID= "Txadvice"TransactionManager= "TransactionManager">        <tx:attributes>            <Tx:methodname="*"Propagation= "REQUIRED"/>        </tx:attributes></Tx:advice><Aop:configExpose-proxy= "true"Proxy-target-class= "true">        <!--implement transactions only for the business logic layer -        <Aop:pointcutID= "Txpointcut"expression= "Execution (* com.weiaigongdi.access). Service: *+.*(..))"/>        <Aop:advisorID= "Txadvisor"Advice-ref= "Txadvice"Pointcut-ref= "Txpointcut"/></Aop:config><BeanID= "TransactionManager"class= "Org.springframework.jdbc.datasource.DataSourceTransactionManager">          < Propertyname= "DataSource"ref= "DS1" /> </Bean> 

Spring Transaction Properties