In SSM projects, often seen on a class or method in the business layer @Transactional comments, just know that the role of this comment is transaction management, but which specific attributes, to be rolled back in any case, really is not so clear . So I read some online video and blog, a preliminary understanding of Spring's transaction management. Here are some of the main concepts of record, if you want to quickly learn to use and understand the transaction management, it is recommended to related videos. I see the https://www.imooc.com/learn/478 .
First, to understand Spring's transaction management, we must first understand what is a transaction, the transaction characteristics which do not comply with these characteristics of what problems will arise. Only by understanding these, you will understand what to do transaction management.
1. Transaction: a set of operations on the logical set of operations either all succeed, or all fail.
2. Characteristics of the transaction
(1) Atomic: A transaction is an indivisible unit of work, either all operations in the transaction success after submitting, or all fail.
(2) Consistency: the integrity of the data before and after the transaction is committed to be consistent.
(3) Isolation: no interference between the plurality of transaction data between the transaction to be isolated from each other.
(4) Persistence: a single transaction is committed, it changed the database will be permanent, even if the database were to fail to deal with its impact.
3. If the transaction does not comply with the above characteristics, it appears dirty read, non-repeatable read and phantom read problems
(1) Dirty read: A transaction reads a data overwrite another transaction but not yet committed. If these data are rolled back, the first transaction reads the data will be invalid.
(2) non-repeatable read: In the same transaction, the same data repeatedly read result differs.
(3) Magic Reading: After reading the data in a transaction, insert some other transaction record. When the query again, the first transaction will not find the original records.
Second, the understanding of the basic concepts of these, go to understand the Spring transaction management interfaces provided.
1.PlatformTransactionManager: Platform Transaction Manager Interface. Spring provides different implementations for different persistence framework, as provided for the Spring JDBC DataSourceTransactionManager or MyBatis,
It provides HibernateTransactionManager to Hibernate. Transaction Manager defines some specific transaction operations, such as transaction commits, the transaction is rolled back.
2.TransactionDefinition: transaction definition information. Such as transaction isolation level, propagation behavior, the timeout and read-only.
(1) the transaction isolation level
a) READ_UNCOMMITTED: allows another transaction modifies the data read, but not committed, there will be dirty read, where the reading and unrepeatable phantom read
b) READ_COMMITTED: allows reading after another transaction commits to prevent dirty reads, but there will be non-repeatable read and phantom read.
c) REPEATABLE_READ: read the same data is the same, unless the transaction itself modify the data. Prevents dirty reads and non-repeatable read, phantom read occurs.
d) SERIALIZABLE: This isolation level is full compliance with the ACID isolation levels, to ensure that dirty reads, non-repeatable reads and phantom reads does not occur. However, due to the same read transaction data is completely read serially, so the implementation is very slow.
e) DEAFULT: Spring to use the default isolation level. Use the default isolation level back-end database, MySQL's default every level is REPEATABLE_READ, ORACLE default isolation level is READ_COMMITTED.
(2) propagation behavior, to solve the problem of multiple business layer method calls
a) PROPAGATION_REQUIRED: support for the current transaction. If the current transaction exists, add another transaction to the current transaction; if the current transaction does not exist, create a new transaction, and will first be included.
b) PROPAGATION_SUPPORTS: support for the current transaction. If the current transaction does not exist, perform non-transactional way.
c) PROPAGATION_MANADATORY: support for the current transaction. If the current transaction does not exist, an exception is thrown.
d) PROPAGATION_REQUIRES_NEW: New Transaction, suspend the current transaction, then the transaction is complete new execution of the current transaction.
e) PROPAGATION_NOT_SUPPORTS: performed in a non-transactional manner. If there is a current transaction, pending the current transaction. Another method of execution after the complete execution of the current transaction.
f) PROPAGATION_NEVER: running in non-transactional way. If there is a current transaction, an exception is thrown.
g) PROPAGATION_NESTED: If the current transaction is present, then the second transaction nested within the current transaction.
(3) timeout: defaults to -1. After setting the time-out transaction has not been completed, the transaction is rolled back.
(4) read-only: Specifies the transaction is read-only transactions, default false. If set to true, the presence of additional transactions, delete, and modify database will throw an exception and rolled back.
3.TransactionStatus: Specific operational status of the transaction.
Third, configure the transaction management
1. programmatic transaction management: by writing a transaction manager in the transaction management method, the business layer in this way code is invasive, is rarely used.
transactionTemplate.execute(new TransactionCallbackWithoutResult() {
@Override
protected void doInTransactionWithoutResult(TransactionStatus transactionStatus) {
accountDao.outMoney(out, money);
int i = 1 / 0;
accountDao.inMoney(in, money);
}
});
2. declarative transaction management:
(1) use a proxy to implement transaction management, you need to add a proxy class for each class, when increasing need for transaction management class, add the proxy class is very troublesome. So this is rarely used.
<!--注入代理--> <bean id="accountServiceProxy" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> <!--注入目标对象--> <property name="target" ref="declarativeAccountService" /> <!--注入事物管理器--> <property name="transactionManager" ref="transactionManager" /> <property name="transactionAttributes"> <props> <prop key="transfer">PROPAGATION_REQUIRED,+java.lang.ArithmeticException</prop> </props> </property> </bean>
@Resource(name="accountServiceProxy") private DeclarativeAccountService declarativeAccountService;
(2) use AspectJ to implement transaction management, you need to configure notifications and enhanced section. Require transaction management package or class is very clear.
<!--配置事务通知--> <tx:advice id="txAdvice" transaction-manager="transactionManager"> <tx:attributes> <tx:method name="transfer" propagation="REQUIRED"/> </tx:attributes> </tx:advice> <aop:config> <!--配置切入点--> <aop:pointcut id="aspectJPoint" expression="execution(* imooc.spring.transaction.manage.service.AspectJAccountService+.*(..))" /> <!--配置切面--> <aop:advisor advice-ref="txAdvice" pointcut-ref="aspectJPoint" /> </aop:config>
(3) Management based transaction annotation: 1. Configuration of the steps required transaction manager can be configured in xml, but also can be configured using the annotation on annotation 2. denoted @Transactional class or method.
<tx:annotation-driven transaction-manager="transactionManager" />
Fourth, the use @Transactional annotation points to note
1. On the classes and methods can be marked @Transactional notes, while in class or when @Transactional marked with annotation, property on the transaction management method properties on Hu will override any class method.
2. @ Transactional annotation will only take effect when indicated on the public way mark not being given on other methods, but can not take effect.
3. By default, when no abnormalities transaction (a RuntimeException or subclasses) and if ERROR is thrown, the transaction is rolled back; exception will not rollback the addition.
Ali p3c code specification of requirements when adding attribute labeling rollbackFor transaction management, i.e. @Transactional (rollbackFor = Exception.class).
After reading some of these concepts are in the blog post and video recording, if the wrong place please correct me. If you are interested, can access relevant blog and video links are as follows:
https://www.cnblogs.com/xd502djj/p/10940627.html
https://www.imooc.com/learn/478