spring事务基本配置
参见: Spring MVC事务配置
spring事务传播机制
参见: Spring事务传播机制
简单说一下new和nested的区别。
使用new的时候,外层事务的提交或回滚,与new的事务没有关系。而使用nested时,内层事务最终是提交还是回滚,需要依赖于外层事务。参见下表。
事务传播配置 | 外层事务(set a=1) | 内层事务(set b=2) | 最终结果 |
---|---|---|---|
new | 提交 | 提交 | a=1 && b=2 |
new | 提交 | 回滚 | a=1 |
new | 回滚 | 提交 | b=2 |
new | 回滚 | 回滚 | 什么都不变 |
nested | 提交 | 提交 | a=1 && b=2 |
nested | 提交 | 回滚 | a=1(这种情况需要增加一个配置:<property name="globalRollbackOnParticipationFailure" value="false" /> ) |
nested | 回滚 | 提交 | 什么都不变 |
nested | 回滚 | 回滚 | 什么都不变 |
spring事务隔离机制
Isolation Level(事务隔离等级)
- Serializable:最严格的级别,事务串行执行,资源消耗最大;
- REPEATABLE READ:保证了一个事务不会修改已经由另一个事务读取但未提交(回滚)的数据。避免了“脏读取”和“不可重复读取”的情况,但是带来了更多的性能损失。
- READ COMMITTED:大多数主流数据库的默认事务等级,保证了一个事务不会读到另一个并行事务已修改但未提交的数据,避免了“脏读取”。该级别适用于大多数系统。 4。 Read Uncommitted:保证了读取过程中不会读取到非法数据。隔离级别在于处理多事务的并发问题。
我们知道并行可以提高数据库的吞吐量和效率,但是并不是所有的并发事务都可以并发运行,这需要查看数据库教材的可串行化条件判断了。
这里就不阐述了。
我们首先说并发中可能发生的3种不讨人喜欢的事情
-
Dirty reads–读脏数据。
也就是说,比如事务A的未提交(还依然缓存)的数据被事务B读走,如果事务A失败回滚,会导致事务B所读取的的数据是错误的。
-
non-repeatable reads–数据不可重复读。
比如事务A中两处读取数据-total-的值。在第一读的时候,total是100,然后事务B就把total的数据改成200,事务A再读一次,结果就发现,total竟然就变成200了,造成事务A数据混乱。
-
phantom reads–幻象读数据
这个和non-repeatable reads相似,也是同一个事务中多次读不一致的问题。但是non-repeatable reads的不一致是因为他所要取的数据集被改变了(比如total的数据),而phantom reads所要读的数据的不一致却不是他所要读的数据集改变,而是他的条件数据集改变。比如Select account.id where account.name=“ppgogo*”,第一次读去了6个符合条件的id,第二次读取的时候,由于事务b把一个帐号的名字由"dd"改成"ppgogo1",结果取出来了7个数据。
隔离级别与几种问题的关系
– | Dirty reads | non-repeatable reads | phantom reads |
---|---|---|---|
Serializable | 不会 | 不会 | 不会 |
REPEATABLE READ | 不会 | 不会 | 会 |
READ COMMITTED | 不会 | 会 | 会 |
Read Uncommitted | 会 | 会 | 会 |
DEFALT(使用底层数据库的默认隔离级别) | ? | ? | ? |
spring事务管理其他配置
readOnly
标记事务只读。只读事务会被优化;但是“只读”事务中其实可以写数据。
timeout
事务超时时间
rollbackFor/rollbackForClassName
标记哪些异常会引发回滚。默认情况下,所有RuntimeException都会引发回滚;所有其它异常(checked-exception)都不引发回滚。如果需要针对某种checked-exception进行回滚,则需要为事务配置rollbackFor或者rollbackForClassName
noRollbackFor/noRollbackForClassName
标记哪些异常不会引发回滚。默认情况下,所有RuntimeException都会引发回滚;所有其它异常(checked-exception)都不引发回滚。如果需要使得某种RuntimeException不进行回滚,则需要为事务配置noRollbackFor/noRollbackForClassName。
spring事务机制基本原理
aop
无论配置方式,还是注解方式,spring都是基于spring aop来进行事务管理。 即,在事务切入点处,生成一个动态代理。在代理中管理事务(开启、传播、提交或回滚等)。可参见下面两张图:
两张图都是调用isLocked()方法时的线程栈。可以看到,第二章图是通过动态代理来调用isLocked()方法的,而第一张图则不是。
动态代理的方式简化了代码的开发;但是也引入了一些小问题。后面会提。
线程上下文
spring会将事务相关的有状态数据(数据库连接、hibernate的session等)放在线程上下文中(ThreadLocal)。因此,事务间的传播关系、事务开启和关闭的时机,与线程中的方法调用栈很相似。
另外,由于事务与线程相关,因此目前spring的事务管理无法让多个子线程在同一事务内运行。
如何测试
首先来看看如何确定运行时是否使用了事务、事务是如何传播的。
首先在log4j中加入以下配置。严格说只要记录了org.springframework.transaction.support.AbstractPlatformTransactionManager
的日志即可。另一个logger是为了记录SQL的,也可以将它替换成其它logger。
<Logger name="org.springframework.transaction.support.AbstractPlatformTransactionManager" level="DEBUG" additivity="false">
<AppenderRef ref="Console" />
<AppenderRef ref="AuditAsyncAppender" />
</Logger>
<Logger name="org.hibernate.SQL" level="TRACE" additivity="false">
<AppenderRef ref="Console" />
<AppenderRef ref="AuditAsyncAppender" />
</Logger>
然后运行事务相关代码:
@Testpublic void test() {
// 这个方法使用默认的传播方式(REQUIRED)
this.lockServiceByDB.tryLock(LockName.EVENT_LOAN, "23424");
// 这个方法使用REQUIRES_NEW的传播方式
this.lockServiceByDB.isLocked(LockName.EVENT_LOAN, "23424");
}
可以找到如下日志:
2016-07-06 18:01:10,969 DEBUG AbstractPlatformTransactionManager.getTransaction Creating new transaction with name[cn.youcredit.thread.bizaccount.service.impl.LockServiceByDBTestBySpring.test]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT; ‘’,-cn.youcredit.thread.common.exception.ServiceException
【中略】
2016-07-06 18:01:11,297 DEBUG AbstractPlatformTransactionManager.handleExistingTransaction Participating in existing transaction
2016-07-06 18:01:11,309 DEBUG SqlStatementLogger.logStatement
select count(1) as col_0_0_ from db_locks dblock0_ where dblock0_.lockName=? and dblock0_.uniKey=?
2016-07-06 18:01:11,325 DEBUG SqlStatementLogger.logStatement
insert into db_locks (lockName, lockTimeAsLong, uniKey) values (?, ?, ?)
【中略】
2016-07-06 18:01:11,331 DEBUG AbstractPlatformTransactionManager.handleExistingTransaction Suspending current transaction, creating new transaction with name [cn.youcredit.thread.bizaccount.service.impl.LockServiceByDB.isLocked]
【中略】
2016-07-06 18:01:11,335 DEBUG SqlStatementLogger.logStatement
select count(1) as col_0_0_ from db_locks dblock0_ where dblock0_.lockName=? and dblock0_.uniKey=?
2016-07-06 18:01:11,337 DEBUG AbstractPlatformTransactionManager.processCommit Initiating transaction commit
2016-07-06 18:01:11,337 DEBUG HibernateTransactionManager.doCommit Committing Hibernate transaction on Session [SessionImpl(PersistenceContext[entityKeys=[],collectionKeys=[]];ActionQueue[insertions=org.hibernate.engine.spi.ExecutableList@1a9ea4d9 updates=org.hibernate.engine.spi.ExecutableList@59ca0db6 deletions=org.hibernate.engine.spi.ExecutableList@33293dac orphanRemovals=org.hibernate.engine.spi.ExecutableList@384841e3 collectionCreations=org.hibernate.engine.spi.ExecutableList@571f925f collectionRemovals=org.hibernate.engine.spi.ExecutableList@5eb192b7 collectionUpdates=org.hibernate.engine.spi.ExecutableList@248f1090 collectionQueuedOps=org.hibernate.engine.spi.ExecutableList@5eb20abb unresolvedInsertDependencies=UnresolvedEntityInsertActions[]])]
【中略】
2016-07-06 18:01:11,339 DEBUG AbstractPlatformTransactionManager.cleanupAfterCompletion Resuming suspended transaction after completion of inner transaction
2016-07-06 18:01:11,340 DEBUG AbstractPlatformTransactionManager.proce***ollback Initiating transaction rollback
2016-07-06 18:01:11,340 DEBUG HibernateTransactionManager.doRollback Rolling back Hibernate transaction on Session [SessionImpl(PersistenceContext[entityKeys=[EntityKey[cn.youcredit.thread.common.model.auth.UserInfo#system], EntityKey[cn.youcredit.thread.bizaccount.bean.DBLock#139], EntityKey[cn.youcredit.thread.common.model.auth.UserGroupInfo#500]],collectionKeys=[]];ActionQueue[insertions=org.hibernate.engine.spi.ExecutableList@2f90ad92 updates=org.hibernate.engine.spi.ExecutableList@4710332d deletions=org.hibernate.engine.spi.ExecutableList@7930de44 orphanRemovals=org.hibernate.engine.spi.ExecutableList@52891a77 collectionCreations=org.hibernate.engine.spi.ExecutableList@785fd189 collectionRemovals=org.hibernate.engine.spi.ExecutableList@3e900cf4 collectionUpdates=org.hibernate.engine.spi.ExecutableList@412d379c collectionQueuedOps=org.hibernate.engine.spi.ExecutableList@5b6dc76c unresolvedInsertDependencies=UnresolvedEntityInsertActions[]])]
从日志中可以清楚的看到事务操作、传播的过程:
-
首先,运行LockServiceByDBTestBySpring.test()方法时,创建了一个新事务。
这是SpringJUnit4ClassRunner的事务逻辑,即每一个单元测试都会启动一个事务,并且默认情况下,该事务会回滚。
-
然后,在执行到this.lockServiceByDB.tryLock()方法时,由于传播方式是REQUIRED,因此会加入当当前已有的事务中,并执行两条sql。
-
接着执行this.lockServiceByDB.isLocked()方法。
由于这个方法的事务传播方式是REQUIRES_NEW,因此会挂起当前事务,并创建一个新的事务,在新的事务中执行一条SQL。
-
新事务执行并提交之后,恢复被挂起的上层事务。并继续执行。由于后面没有其它逻辑、代码,因此开始回滚外层事务。
常见问题
事务标记在protcted或private方法上,导致事务失效
spring的事务注解只对public方法生效,对protcted、friendly(默认)、private方法无效。如果在后面这些方法上标记事务注解,其效果等于没有标记。
注解继承不当,导致事务失效
Java注解的基本继承关系如下。spring的Transactional注解上有Inherited的元注解。
- | 未写@Inherited: | 写了@Inherited的 |
---|---|---|
子类的类上能否继承到父类的类上的注解? | 否 | 能 |
子类方法,实现了父类上的抽象方法,这个方法能否继承到注解? | 否 | 否 |
子类方法,继承了父类上的方法,这个方法能否继承到注解? | 能 | 能 |
子类方法,覆盖了父类上的方法,这个方法能否继承到注解? | 否 | 否 |
例如下面的代码中,虽然Son在类级别上声明了事务,但是它的tryLocked()方法并不会启动新的事务。因为它在父类中没有声明事务。
public class Father{
public void tryLocked(){}
}
@Transactional(REQUIRES_NEW)
public class Son extends Father{
}
使用this方式调用,导致事务失效
对于spring aop的动态代理来说,被代理实例和方法是一个“黑盒”。只有在“黑盒”之外才能进行事务管理。而this调用是黑盒内部的调用逻辑,代理无法感知。
与this类似的还有super关键字。
因此,像下文这样的代码中,isLocked()方法并不会启动新的事务。
@Transactional(REQUIRES_NEW)
public void isLocked(){
……
}
@Transactional()
public void tryLock(){
this.isLocked();
……
}
事务与查询
虽然查询操作并不更新数据,但是查询也需要事务。尤其对hibernate来说。
hibernate操作数据库时,需要获取到一个hibernate的session。而这个session也由HibernateTransactionManager来管理。管理的方式与其它有状态数据一样,都是放在ThreadLocal中。如果线程上没有事务管理器,那么就拿不到session。hibernate做查询时就会报错:
org.hibernate.HibernateException: Could not obtain transaction-synchronized Session for current thread at org.springframework.orm.hibernate4.SpringSessionContext.currentSession(SpringSessionContext.java:134) ~[spring-orm-4.2.2.RELEASE.jar:4.2.2.RELEASE]
有时候明明没有写事务注解,也能执行查询,那么多半是在某个地方默认、或者“偷偷”开了事务。比如继承SpringTestCase的单元测试会默认开启事务。或者web环境下,线程池中的线程上遗留了以前绑定的事务管理器。
©著作权归作者所有:来自51CTO博客作者winters1224的原创作品,请联系作者获取转载授权,否则将追究法律责任 Spring事务 https://blog.51cto.com/winters1224/2463949