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.