Spring USES annotations for transaction management configuration

2020-07-21 08:02:47
OfStack

Steps:

Step 1. Introduced in the spring configuration file < tx: > The namespace


<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:tx="http://www.springframework.org/schema/tx"
 xsi:schemaLocation="http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
 http://www.springframework.org/schema/tx
 http://www.springframework.org/schema/tx/spring-tx-2.0.xsd">

Step 2. bean with the @Transactional annotation is automatically configured for declarative transaction support


<!--  Transaction manager configuration , Hibernate Single data source transaction  -->
  <bean id="defaultTransactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
    <property name="sessionFactory" ref="sessionFactory" />
  </bean>
  
  <!--  use annotation Define the transaction  -->
  <tx:annotation-driven transaction-manager="defaultTransactionManager" proxy-target-class="true" />

Step 3. At the interface or class declaration, write 1 @Transactional.

If you write only on the interface, the implementation class of the interface inherits, and the concrete methods of the implementation class of the interface override the Settings at the class declaration

@Transactional // Class level annotations, methods that apply to all public methods in a class

The propagation behavior and isolation level of the transaction

When using spring's annotated transaction management, you may be at a loss as to the propagation behavior and isolation level of the transaction.

Things annotated: @Transactional

When labeled in front of a class, all methods in the class are processed. Examples:


@Transactional
public class TestServiceBean implements TestService {}

When certain methods in a class do not need things:


@Transactional
public class TestServiceBean implements TestService {  
  private TestDao dao;  
  public void setDao(TestDao dao) {
    this.dao = dao;
  }  
  @Transactional(propagation = Propagation.NOT_SUPPORTED)
  public List<Object> getAll() {
    return null;
  }  
}

Introduction to the transmission behavior of things:

@Transactional(propagation=Propagation.REQUIRED)

If there is a transaction, add the transaction, or create a new one (by default)

@Transactional(propagation=Propagation.NOT_SUPPORTED)

The container does not open a transaction for this method

@Transactional(propagation=Propagation.REQUIRES_NEW)

Regardless of whether a transaction exists, a new transaction is created, the original transaction is suspended, the new transaction completes, and the old transaction continues to execute

@Transactional(propagation=Propagation.MANDATORY)

Must be executed in an existing transaction or an exception is thrown

@Transactional(propagation=Propagation.NEVER)

Must be executed in a transaction that does not exist, otherwise an exception is thrown (as opposed to ES76en.MANDATORY)

@Transactional(propagation=Propagation.SUPPORTS)

If another bean calls this method and declares a transaction in another bean, then a transaction is used. If the other bean does not declare a transaction, then no transaction is used.

Things timeout setting:

Transactional(timeout=30) // Default is 30 seconds

Transaction isolation level:

@Transactional(isolation = Isolation.READ_UNCOMMITTED)

Reading uncommitted data (dirty reads, non-repeatable reads) is rarely used

@Transactional(isolation = Isolation.READ_COMMITTED)

Read committed data (non-repeatable read and phantom read)

@Transactional(isolation = Isolation.REPEATABLE_READ)

Repeatable reading (phantom reading)

@Transactional(isolation = Isolation.SERIALIZABLE)

serialization

MYSQL: Default is the REPEATABLE_READ level

SQLSERVER: Default is READ_COMMITTED

Dirty read: One transaction reads uncommitted update data from another transaction

Non-repeatable read: In the same 1 transaction, multiple reads of the same 1 data return different results, in other words,

Subsequent reads can read the committed update data of another transaction. Instead, "repeatable reads" are repeated multiple times in the same transaction

When you read the data, you are guaranteed to read the same data, that is, subsequent reads cannot read the committed update data of another transaction

Phantom reads: One transaction reads committed insert data from another transaction

Common parameter descriptions in the @Transactional annotation

参数名称

功能描述

readOnly

该属性用于设置当前事务是否为只读事务，设置为true表示只读，false则表示可读写，默认值为false。例如：@Transactional(readOnly=true)

rollbackFor

该属性用于设置需要进行回滚的异常类数组，当方法中抛出指定异常数组中的异常时，则进行事务回滚。例如：

指定单1异常类：@Transactional(rollbackFor=RuntimeException.class)

指定多个异常类：@Transactional(rollbackFor={RuntimeException.class, Exception.class})

Duration of table

参数名称	功能描述
rollbackForClassName	该属性用于设置需要进行回滚的异常类名称数组，当方法中抛出指定异常名称数组中的异常时，则进行事务回滚。例如：指定单1异常类名称：@Transactional(rollbackForClassName="RuntimeException") 指定多个异常类名称：@Transactional(rollbackForClassName={"RuntimeException","Exception"})
noRollbackFor	该属性用于设置不需要进行回滚的异常类数组，当方法中抛出指定异常数组中的异常时，不进行事务回滚。例如：指定单1异常类：@Transactional(noRollbackFor=RuntimeException.class) 指定多个异常类：@Transactional(noRollbackFor={RuntimeException.class, Exception.class})
noRollbackForClassName	该属性用于设置不需要进行回滚的异常类名称数组，当方法中抛出指定异常名称数组中的异常时，不进行事务回滚。例如：指定单1异常类名称：@Transactional(noRollbackForClassName="RuntimeException") 指定多个异常类名称： @Transactional(noRollbackForClassName={"RuntimeException","Exception"})
propagation	该属性用于设置事务的传播行为，具体取值可参考表6-7。例如：@Transactional(propagation=Propagation.NOT_SUPPORTED,readOnly=true)
isolation	该属性用于设置底层数据库的事务隔离级别，事务隔离级别用于处理多事务并发的情况，通常使用数据库的默认隔离级别即可，基本不需要进行设置
timeout	该属性用于设置事务的超时秒数，默认值为-1表示永不超时

Points to note:

1 @Transactional can only be applied to the public method. For other non-public methods, @ES170en will not report an error if marked, but the method has no transaction function.

2 using spring transaction manager, spring is responsible for opening, committing, and rolling back the database. Default runtime exception (throw new RuntimeException(" comment ");) Will roll back, that is, if an exception is not checked (unchecked); An exception to be caught (throw new Exception(" comment ");) To rollback all exceptions, add @Transactional (rollbackFor={Exception.class, other exceptions}). If you want the unchecked exception not to rollback: @Transactional (notRollbackFor= RunTimeException.class)

As follows:


 @Transactional(rollbackFor=Exception.class) // Specify the rollback , Exception encountered Exception The rollback 
public void methodName() {
 throw new Exception(" annotation ");

 }
 @Transactional(noRollbackFor=Exception.class)// Specifies no rollback , A runtime exception was encountered (throw new RuntimeException(" annotation ");) Will be rolled back 
public ItimDaoImpl getItemDaoImpl() {
 throw new RuntimeException(" annotation ");
 }

3. The @Transactional annotation should only be applied to public visibility methods. If you use the @Transactional annotation on protected, private, or package-ES203en methods, it will not report an error, but the annotated method will not show configured transaction Settings.

4. The @Transactional annotation can be applied to interface definitions and interface methods, class definitions and public methods of classes. Note, however, that the presence of the @ES209en annotation alone is not sufficient to enable transactional behavior; it is just one metadata that can be used by the @ES210en annotation and the above configured beans with appropriate transactional behavior. In the example above, it is < tx:annotation-driven/ > The presence of the element initiates the transactional behavior.

5. The Spring team recommends that you use the @Transactional annotation on specific classes (or methods of classes) and not on any interfaces that the class will implement. You can certainly use the @Transactional annotation on the interface, but this will only take effect if you set up an interport-based proxy. Because annotations are not inherited, this means that if you are using a class-based proxy, the transaction Settings will not be recognized by the class-based proxy, and the object will not be wrapped (and will be recognized as serious) by the transaction proxy. Therefore, please accept the Spring team's recommendation and use the @ES221en annotation on specific classes.