In-depth understanding and case analysis of spring transactions

http://www.cnblogs.com/fjdingsd/p/5632949.html Reference document

<!-- Transaction related configuration-->
	<bean id="transactionManager"
		class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
		<property name="dataSource" ref="dataSource" />
	</bean>
	<tx:advice id="txAdvice" transaction-manager="transactionManager">
		<tx:attributes>
			<tx:method name="insert*" propagation="REQUIRED" read-only="false" isolation="READ_UNCOMMITTED"
				rollback-for="java.lang.Exception" />
			<tx:method name="save*" propagation="REQUIRED" read-only="false" isolation="READ_UNCOMMITTED"
				rollback-for="java.lang.Exception" />
			<tx:method name="update*" propagation="REQUIRED" read-only="false" isolation="READ_UNCOMMITTED"
				rollback-for="java.lang.Exception" />
			<tx:method name="modify*" propagation="REQUIRED" read-only="false" isolation="READ_UNCOMMITTED"
				rollback-for="java.lang.Exception" />
			<tx:method name="delete*" propagation="REQUIRED" read-only="false" isolation="READ_UNCOMMITTED"
				rollback-for="java.lang.Exception" />
		</tx:attributes>
	</tx:advice>

//propagation="REQUIRED": Spring configures the propagation property of the transaction, which is the default propagation property of spring. If there is no current transaction, a new transaction is created, and if there is a current transaction, it is directly added to the existing transaction.

//isolation="READ_UNCOMMITTED": The isolation level of spring configuration transaction is uncommitted read, which will generate dirty reads. For example, thread 1 needs to update the order remark to 1 but has not yet submitted it. At this time, thread 2 can read the order remark as 1 in another transaction.

	<!-- Transaction related configuration-->
	<bean id="transactionManager"
		class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
		<property name="dataSource" ref="dataSource" />
	</bean>
	<tx:annotation-driven transaction-manager="transactionManager"/>


 @Transactional(propagation=Propagation.REQUIRED, isolation=Isolation.READ_COMMITTED)  
    @Override
    public void updateOrderMemoInfo(Map<String, Object> params) {

}

//Annotation-based transaction configuration, configure the current transaction propagation attribute to REQUIRED, and the transaction isolation level to READ_COMMITTED

//Propagation properties of the transaction

//REQUIRED: Support the current transaction. If there is no current transaction, create a new transaction. This is the default propagation property of spring.

//REQUIRES_NEW: A new transaction is created each time. If there is already a transaction, the current transaction will be suspended. The newly created transaction has nothing to do with the current transaction and is two completely independent transactions. The failure of the outer transaction will not affect the inner transaction, and the failure of the inner transaction may not affect the outer transaction.

//SUPPORTS: Support the current transaction, if there is no current transaction, it will run in a non-transactional mode.

//NOT_SUPPORTED: run in a non-transactional way, if there is a current transaction, suspend the current transaction.

//NEVER: Runs in a non-transactional manner, throwing an exception if there is currently a transaction.

//Isolation level of database transactions

//Read-Uncommitted: Uncommitted read. One transaction modifies the data but the transaction has not yet committed, and another transaction reads the uncommitted data, which will lead to dirty reads.

//Read-Committed: Commit to read. One transaction reads the same data twice, and another transaction modifies the data after the first read, which will cause the data read twice by the first transaction to be inconsistent, resulting in non-repeatable reads. Dirty reads can be avoided

//Repeatable-Read: The first transaction modifies data within a certain range, and the second transaction adds a piece of data within this range, which will cause the first transaction to update one less piece of data, resulting in phantom read. Dirty reads and non-repeatable reads can be avoided.

//Serializable: All transactions are executed one by one serially, which can avoid dirty reads, non-repeatable reads, and phantom reads. Highest isolation level.

//Summary: The higher the isolation level, the better the data integrity and consistency can be guaranteed, but the greater the impact on concurrent performance,

//isolation level of spring transaction

//DEFAULT: Spring's default isolation level, the database isolation level is used by default.

//READ_UNCOMMITTED: Allowing a transaction to read data that has not yet been committed by another transaction will result in dirty reads.

//READ_COMMITTED: It is guaranteed that a transaction can only be read by another transaction after it has been committed.

//REPEATABLE_READ: Can prevent dirty reads and non-repeatable reads

//SERIALIZABLE: The highest isolation level, transactions will be executed sequentially.