Spring transaction isolation level, propagation behavior and spring+mybatis+atomikos realize distributed transaction management

The content of this article is about spring transaction isolation level, propagation behavior and spring mybatis atomikos implementation of distributed transaction management. It has certain reference value. Friends in need can refer to it. I hope it will be helpful to you. help.

1. Definition of transaction: A transaction refers to a collection of multiple operating units. The operations of multiple units are indivisible as a whole. Either the operations are unsuccessful or they are all successful. It must follow four principles (ACID).

1. Atomicity: That is, a transaction is an indivisible smallest unit of work, and all operations within the transaction are either done or none;

2. Consistency : The data in the database is in the correct state before the transaction is executed, and the data in the database should still be in the correct state after the transaction is completed. , that is, the data integrity constraint has not been destroyed; such as bank transfer, A transfers money to B, it must be guaranteed that A's money must be transferred to B, and there will never be a situation where A's money is transferred but B does not receive it, otherwise the data in the database will be inconsistent. (incorrect) status.

3. Isolation : The execution of concurrent transactions does not affect each other. Operations within one transaction have no impact on other transactions. This requires transactions Isolation level to specify isolation;

4. Durability (Durability) : Once a transaction is successfully executed, its changes to the database data must be permanent and will not Data inconsistency or loss may occur due to, for example, system failure or power outage.
   

2. Types of transactions

1. The database is divided into local transactions and global transactions

• Local transactions: ordinary transactions, independent of a database, which can guarantee the ACID of operations on the database.

• Distributed transactions: transactions involving two or more database sources, that is, transactions spanning multiple databases of the same type or heterogeneous types (composed of local transactions of each database), distributed The purpose of formal transactions is to ensure the ACID of all operations of these local transactions, so that transactions can span multiple databases;

Java transaction types are divided into JDBC transactions and JTA transactions

• JDBC transaction: It is the local transaction in the database transaction mentioned above, controlled and managed through the connection object.

• JTA transaction: JTA refers to Java Transaction API (Java Transaction API), which is the Java EE database transaction specification. JTA only provides a transaction management interface, which is controlled by the application Server vendors (such as WebSphere Application Server) provide implementations. JTA transactions are more powerful than JDBC and supports distributed transactions.

According to whether it is programmed, it is divided into declarative transactions and programmatic transactions. Please refer to http://blog.csdn.net/liaohaojian/article/details/70139151

• Declarative transactions: implemented through XML configuration or annotations.

• Programmatic transactions: Implemented through programming code when business logic is needed, with smaller granularity.

3. Spring transaction isolation level: spring has five isolation levels, which are defined in the TransactionDefinition interface. Looking at the source code, we can see that its default isolation_default (the default level of the underlying database), and the other four isolation levels are consistent with the database isolation level.

1. ISOLATION_DEFAULT: Use the default isolation level of the underlying database, whatever the database administrator sets

2. ISOLATION_READ_UNCOMMITTED (uncommitted read): The lowest isolation level, the transaction can be read by other transactions before it is submitted (phantom reads, dirty reads, and non-repeatable reads will occur)

3. ISOLATION_READ_COMMITTED (read committed) : A transaction can only be read by other transactions after it is submitted (this isolation level prohibits other transactions from reading the data of uncommitted transactions, so It will still cause phantom reading and non-repeatable reading), sql server default level

4. ISOLATION_REPEATABLE_READ (repeatable reading) : repeatable reading, ensuring that multiple reads are performed at the same time When a piece of data is generated, its value is consistent with the content at the beginning of the transaction, and it is prohibited to read uncommitted data from other transactions (this isolation can basically prevent dirty reads and non-repeatable reads (the focus is on modification), but phantom reads will occur) (Focus on adding and deleting)) (MySql default level, changes can be made through set transaction isolation level level)

5. ISOLATION_SERIALIZABLE (Serialization): The most expensive and most reliable isolation level (this isolation level can prevent dirty reads, non-repeatable reads, and phantom reads)

1. Lost update: Two transactions update a row of data at the same time. The update of the last transaction will overwrite the update of the first transaction, resulting in the loss of the data updated by the first transaction. This It is caused by no locking;

2. Phantom reading: During the same transaction operation, the same data is read multiple times (different transactions) in different time periods, and the read content is inconsistent. (Generally, the number of lines becomes more or less).

3. Dirty read: A transaction reads the content of another transaction that is not mentioned, which is a dirty read.

4. Non-repeatable reading: In the same transaction, the content read multiple times is inconsistent (generally the number of rows remains unchanged, but the content changes).

The difference between phantom reading and non-repeatable reading: The focus of phantom reading is insertion and deletion, that is, the second query will find that the data is better than the first The query data becomes less or more, giving people an illusion. The key point of non-repeatable reading is modification, that is, the second query will find that the query results are inconsistent with the first query results, that is, The first time results are no longer reproducible.

The higher the database isolation level, the higher the execution cost and the worse the concurrent execution capability. Therefore, comprehensive considerations must be taken when developing and using actual projects. In order to consider concurrency performancegenerally use submit Read isolation level, it can avoid lost updates and dirty reads. Although non-repeatable reads and phantom reads cannot be avoided, pessimistic locks or optimistic locks can be used to solve these problems when possible.

4. Communication behavior: There are seven major communication behaviors, which are also defined in the TransactionDefinition interface.

1. PROPAGATION_REQUIRED: Supports the current transaction. If there is no current transaction, create a new one.

2. PROPAGATION_SUPPORTS: Supports the current transaction. If there is no transaction currently, it will be executed non-transactionally (there is a note in the source code, which is not clear, so leave it for later) will be studied later).
   

3. PROPAGATION_MANDATORY: Supports the current transaction. If there is no current transaction, an exception will be thrown (it must be executed in an existing transaction. The business Methods cannot initiate their own transactions on their own).
   

4. PROPAGATION_REQUIRES_NEW: Always create a new transaction. If there is currently a transaction, the original transaction will be suspended.
   

5. PROPAGATION_NOT_SUPPORTED: The current transaction is not supported and is always executed in a non-transactional manner. If the current transaction exists, the transaction is suspended.
   

6. PROPAGATION_NEVER: The current transaction is not supported; if the current transaction exists, an exception is thrown.
   

7. PROPAGATION_NESTED: If the current transaction exists, it is executed in a nested transaction. If there is no current transaction, it performs an operation similar to PROPAGATION_REQUIRED (note : When applied to JDBC, only applicable to JDBC 3.0 or above driver).
   

5.Spring transaction support

1.spring provides many built-in transaction managers that support Different data sources. There are three common categories

• DataSourceTransactionManager: Under the org.springframework.jdbc.datasource package, the data source transaction management class, Provides transaction management for a single javax.sql.DataSource data source, as long as it is used for JDBC and Mybatis framework transaction management.

• HibernateTransactionManager: Under the org.springframework.orm.hibernate3 package, the data source transaction management class provides support for a single org.hibernate.SessionFactory transaction for integration. Transaction management in Hibernate framework; Note: This transaction manager only supports Hibernate3 version, and Spring3.0 version only supports Hibernate 3.2 version;
  

• JtaTransactionManager: Located in the org.springframework.transaction.jta package, it provides support for distributed transaction management, and delegates transaction management to the Java EE application server, or customizes a local JTA transaction manager, nested into the application.
  

The built-in transaction managers all inherit the abstract class AbstractPlatformTransactionManager, and AbstractPlatformTransactionManager inherits the interface PlatformTransactionManager

The core of the Spring framework's support for transaction management is the transaction manager Abstract: For different data access frameworks, the strategy interface PlatformTransactionManager is implemented to support transaction management of multiple data access frameworks.

PlatformTransactionManager interface is defined as follows

The TransactionStatus interface is defined as follows:

public interface TransactionStatus extends SavepointManager {  
       boolean isNewTransaction();  //返回当前事务是否是新的事务
       boolean hasSavepoint();  //返回当前事务是否有保存点
       void setRollbackOnly();  //设置事务回滚
       boolean isRollbackOnly();  //设置当前事务是否应该回滚
       void flush();  //用于刷新底层会话中的修改到数据库，一般用于刷新如Hibernate/JPA的会话，可能对如JDBC类型的事务无任何影响；
       boolean isCompleted();  //返回事务是否完成
}

2. Spring distributed transaction configuration

• References the JNDI data source of the application server (such as Tomcat) to indirectly implement JTA transactions Management relies on the application server

• to directly integrate JOTM (official website: http://jotm.objectweb.org/) and Atomikos (official website: https://www.atomikos.com/ ) Provides JTA transaction management (no application server support, often used for unit testing)

• Use application server-specific transaction managers to use the advanced features of JTA transactions (Weblogic, Websphere)

1). Reference the JNDI data source of the application server (such as Tomcat) to indirectly implement JTA transaction management. The configuration is as follows

2) Use Atomikos to implement distributed transaction management , the configuration is as follows:

  
	
	
    
	
		
	
	
	
		
			
				classpath:public.properties
			
		
	
	 
          
                 
              
             
        
          
          
         
     
     
       
     	
     	
     	
     	
     	
     	
            
                ${db.jdbcUrlOne}
                ${user}
                ${password}
            
        
      
	  
		
		
		
		
		
		
            
                ${db.jdbcUrlTwo}
                ${user}
                ${password}
            
        
      
     
      
          
             
          
          
    
      
         
         
         
         
	
	  
         
         
         
         
	
	 
	
        
        
             
        
      
	
	    
	          
	    
	
	
	    
	        
	            
	        
	        
	            
	     
	    
	        
	
	
		
		    
			
			
			
			
			
			
			
		
	
	
	    
	    
	    
	
	
	
		
        
		
	
	
		
			org.springframework.web.servlet.view.InternalResourceView
		
		
		
			/
		
		
		
			.jsp
		
	
	
	  
          
              
                  
                      
                        no  
                        105,179,90  
                        red  
                        200  
                        60  
                        80  
                        code  
                        4  
                        宋体,楷体,微软雅黑  
                      
                  
              
          
    
      
          
          
          
	

The above is the detailed content of Spring transaction isolation level, propagation behavior and spring+mybatis+atomikos realize distributed transaction management. For more information, please follow other related articles on the PHP Chinese website!