spring特有的事务传播行为,spring支持7种事务传播行为,肯定客户端和被调用端的事务边界(说得通俗一点就是多个具备事务控制的service的相互调用时所造成的复杂的事务边界控制)下图所示为7钟事务传播机制git
ogithub
传播行为spring |
含义数据库 |
PROPAGATION_REQUIRED(XML文件中为REQUIRED)bash |
表示当前方法必须在一个具备事务的上下文中运行,若有客户端有事务在进行,那么被调用端将在该事务中运行,不然的话从新开启一个事务。(若是被调用端发生异常,那么调用端和被调用端事务都将回滚)app |
PROPAGATION_SUPPORTS(XML文件中为SUPPORTS)ide |
表示当前方法没必要须要具备一个事务上下文,可是若是有一个事务的话,它也能够在这个事务中运行post |
PROPAGATION_MANDATORY(XML文件中为MANDATORY)测试 |
表示当前方法必须在一个事务中运行,若是没有事务,将抛出异常ui |
PROPAGATION_NESTED(XML文件中为NESTED) |
表示若是当前方法正有一个事务在运行中,则该方法应该运行在一个嵌套事务中,被嵌套的事务能够独立于被封装的事务中进行提交或者回滚。若是封装事务存在,而且外层事务抛出异常回滚,那么内层事务必须回滚,反之,内层事务并不影响外层事务。若是封装事务不存在,则同PROPAGATION_REQUIRED的同样 |
PROPAGATION_NEVER(XML文件中为NEVER) |
表示当方法务不该该在一个事务中运行,若是存在一个事务,则抛出异常 |
PROPAGATION_REQUIRES_NEW(XML文件中为REQUIRES_NEW) |
表示当前方法必须运行在它本身的事务中。一个新的事务将启动,并且若是有一个现有的事务在运行的话,则这个方法将在运行期被挂起,直到新的事务提交或者回滚才恢复执行。 |
PROPAGATION_NOT_SUPPORTED(XML文件中为NOT_SUPPORTED) |
表示该方法不该该在一个事务中运行。若是有一个事务正在运行,他将在运行期被挂起,直到这个事务提交或者回滚才恢复执行 |
Spring配置声明式事务:
* 配置DataSource
* 配置事务管理器
* 事务的传播特性
* 那些类那些方法使用事务
Spring配置文件中关于事务配置老是由三个组成部分,分别是DataSource、TransactionManager和代理机制这三部分,不管哪一种配置方式,通常变化的只是代理机制这部分。
DataSource、TransactionManager这两部分只是会根据数据访问方式有所变化,好比使用Hibernate进行数据访问 时,DataSource实际为SessionFactory,TransactionManager的实现为 HibernateTransactionManager。
根据代理机制的不一样,Spring事务的配置又有几种不一样的方式:
第一种方式:每一个Bean都有一个代理
第二种方式:全部Bean共享一个代理基类
第三种方式:使用拦截器
第四种方式:使用tx标签配置的拦截器
第五种方式:全注解
注意点:
一、Spring的事务边界是在调用业务方法以前开始的,业务方法执行完毕以后来执行commit 或者rollback,取决因而否抛出runtime异常。
咱们为User1Service和User2Service相应方法加上Propagation.REQUIRED
属性。
User1Service方法:
@Service
public class User1ServiceImpl implements User1Service {
//省略其余...
@Override
@Transactional(propagation = Propagation.REQUIRED)
public void addRequired(User1 user){
user1Mapper.insert(user);
}
}复制代码
User2Service方法:
@Service
public class User2ServiceImpl implements User2Service {
//省略其余...
@Override
@Transactional(propagation = Propagation.REQUIRED)
public void addRequired(User2 user){
user2Mapper.insert(user);
}
@Override
@Transactional(propagation = Propagation.REQUIRED)
public void addRequiredException(User2 user){
user2Mapper.insert(user);
throw new RuntimeException();
}
}复制代码
此场景外围方法没有开启事务。
验证方法1:
@Override
public void notransaction_exception_required_required(){
User1 user1=new User1();
user1.setName("张三");
user1Service.addRequired(user1);
User2 user2=new User2();
user2.setName("李四");
user2Service.addRequired(user2);
throw new RuntimeException();
}复制代码
验证方法2:
@Override
public void notransaction_required_required_exception(){
User1 user1=new User1();
user1.setName("张三");
user1Service.addRequired(user1);
User2 user2=new User2();
user2.setName("李四");
user2Service.addRequiredException(user2);
}复制代码
分别执行验证方法,结果:
验证方法序号 | 数据库结果 | 结果分析 |
---|---|---|
1 | “张三”、“李四”均插入。 | 外围方法未开启事务,插入“张三”、“李四”方法在本身的事务中独立运行,外围方法异常不影响内部插入“张三”、“李四”方法独立的事务。 |
2 | “张三”插入,“李四”未插入。 | 外围方法没有事务,插入“张三”、“李四”方法都在本身的事务中独立运行,因此插入“李四”方法抛出异常只会回滚插入“李四”方法,插入“张三”方法不受影响。 |
结论:经过这两个方法咱们证实了在外围方法未开启事务的状况下Propagation.REQUIRED
修饰的内部方法会新开启本身的事务,且开启的事务相互独立,互不干扰。
外围方法开启事务,这个是使用率比较高的场景。
验证方法1:
@Override
@Transactional(propagation = Propagation.REQUIRED)
public void transaction_exception_required_required(){
User1 user1=new User1();
user1.setName("张三");
user1Service.addRequired(user1);
User2 user2=new User2();
user2.setName("李四");
user2Service.addRequired(user2);
throw new RuntimeException();
}复制代码
验证方法2:
@Override
@Transactional(propagation = Propagation.REQUIRED)
public void transaction_required_required_exception(){
User1 user1=new User1();
user1.setName("张三");
user1Service.addRequired(user1);
User2 user2=new User2();
user2.setName("李四");
user2Service.addRequiredException(user2);
}复制代码
验证方法3:
@Transactional
@Override
public void transaction_required_required_exception_try(){
User1 user1=new User1();
user1.setName("张三");
user1Service.addRequired(user1);
User2 user2=new User2();
user2.setName("李四");
try {
user2Service.addRequiredException(user2);
} catch (Exception e) {
System.out.println("方法回滚");
}
}复制代码
分别执行验证方法,结果:
验证方法序号 | 数据库结果 | 结果分析 |
---|---|---|
1 | “张三”、“李四”均未插入。 | 外围方法开启事务,内部方法加入外围方法事务,外围方法回滚,内部方法也要回滚。 |
2 | “张三”、“李四”均未插入。 | 外围方法开启事务,内部方法加入外围方法事务,内部方法抛出异常回滚,外围方法感知异常导致总体事务回滚。 |
3 | “张三”、“李四”均未插入。 | 外围方法开启事务,内部方法加入外围方法事务,内部方法抛出异常回滚,即便方法被catch不被外围方法感知,整个事务依然回滚。 |
结论:以上试验结果咱们证实在外围方法开启事务的状况下Propagation.REQUIRED
修饰的内部方法会加入到外围方法的事务中,全部Propagation.REQUIRED
修饰的内部方法和外围方法均属于同一事务,只要一个方法回滚,整个事务均回滚。
咱们为User1Service和User2Service相应方法加上Propagation.REQUIRES_NEW
属性。
User1Service方法:
@Service
public class User1ServiceImpl implements User1Service {
//省略其余...
@Override
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void addRequiresNew(User1 user){
user1Mapper.insert(user);
}
@Override
@Transactional(propagation = Propagation.REQUIRED)
public void addRequired(User1 user){
user1Mapper.insert(user);
}
}复制代码
User2Service方法:
@Service
public class User2ServiceImpl implements User2Service {
//省略其余...
@Override
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void addRequiresNew(User2 user){
user2Mapper.insert(user);
}
@Override
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void addRequiresNewException(User2 user){
user2Mapper.insert(user);
throw new RuntimeException();
}
}复制代码
外围方法没有开启事务。
验证方法1:
@Override
public void notransaction_exception_requiresNew_requiresNew(){
User1 user1=new User1();
user1.setName("张三");
user1Service.addRequiresNew(user1);
User2 user2=new User2();
user2.setName("李四");
user2Service.addRequiresNew(user2);
throw new RuntimeException();
}复制代码
验证方法2:
@Override
public void notransaction_requiresNew_requiresNew_exception(){
User1 user1=new User1();
user1.setName("张三");
user1Service.addRequiresNew(user1);
User2 user2=new User2();
user2.setName("李四");
user2Service.addRequiresNewException(user2);
}复制代码
分别执行验证方法,结果:
验证方法序号 | 数据库结果 | 结果分析 |
---|---|---|
1 | “张三”插入,“李四”插入。 | 外围方法没有事务,插入“张三”、“李四”方法都在本身的事务中独立运行,外围方法抛出异常回滚不会影响内部方法。 |
2 | “张三”插入,“李四”未插入 | 外围方法没有开启事务,插入“张三”方法和插入“李四”方法分别开启本身的事务,插入“李四”方法抛出异常回滚,其余事务不受影响。 |
结论:经过这两个方法咱们证实了在外围方法未开启事务的状况下Propagation.REQUIRES_NEW
修饰的内部方法会新开启本身的事务,且开启的事务相互独立,互不干扰。
外围方法开启事务。
验证方法1:
@Override
@Transactional(propagation = Propagation.REQUIRED)
public void transaction_exception_required_requiresNew_requiresNew(){
User1 user1=new User1();
user1.setName("张三");
user1Service.addRequired(user1);
User2 user2=new User2();
user2.setName("李四");
user2Service.addRequiresNew(user2);
User2 user3=new User2();
user3.setName("王五");
user2Service.addRequiresNew(user3);
throw new RuntimeException();
}复制代码
验证方法2:
@Override
@Transactional(propagation = Propagation.REQUIRED)
public void transaction_required_requiresNew_requiresNew_exception(){
User1 user1=new User1();
user1.setName("张三");
user1Service.addRequired(user1);
User2 user2=new User2();
user2.setName("李四");
user2Service.addRequiresNew(user2);
User2 user3=new User2();
user3.setName("王五");
user2Service.addRequiresNewException(user3);
}复制代码
验证方法3:
@Override
@Transactional(propagation = Propagation.REQUIRED)
public void transaction_required_requiresNew_requiresNew_exception_try(){
User1 user1=new User1();
user1.setName("张三");
user1Service.addRequired(user1);
User2 user2=new User2();
user2.setName("李四");
user2Service.addRequiresNew(user2);
User2 user3=new User2();
user3.setName("王五");
try {
user2Service.addRequiresNewException(user3);
} catch (Exception e) {
System.out.println("回滚");
}
}复制代码
分别执行验证方法,结果:
验证方法序号 | 数据库结果 | 结果分析 |
---|---|---|
1 | “张三”未插入,“李四”插入,“王五”插入。 | 外围方法开启事务,插入“张三”方法和外围方法一个事务,插入“李四”方法、插入“王五”方法分别在独立的新建事务中,外围方法抛出异常只回滚和外围方法同一事务的方法,故插入“张三”的方法回滚。 |
2 | “张三”未插入,“李四”插入,“王五”未插入。 | 外围方法开启事务,插入“张三”方法和外围方法一个事务,插入“李四”方法、插入“王五”方法分别在独立的新建事务中。插入“王五”方法抛出异常,首先插入 “王五”方法的事务被回滚,异常继续抛出被外围方法感知,外围方法事务亦被回滚,故插入“张三”方法也被回滚。 |
3 | “张三”插入,“李四”插入,“王五”未插入。 | 外围方法开启事务,插入“张三”方法和外围方法一个事务,插入“李四”方法、插入“王五”方法分别在独立的新建事务中。插入“王五”方法抛出异常,首先插入“王五”方法的事务被回滚,异常被catch不会被外围方法感知,外围方法事务不回滚,故插入“张三”方法插入成功。 |
结论:在外围方法开启事务的状况下Propagation.REQUIRES_NEW
修饰的内部方法依然会单独开启独立事务,且与外部方法事务也独立,内部方法之间、内部方法和外部方法事务均相互独立,互不干扰。
咱们为User1Service和User2Service相应方法加上Propagation.NESTED
属性。
User1Service方法:
@Service
public class User1ServiceImpl implements User1Service {
//省略其余...
@Override
@Transactional(propagation = Propagation.NESTED)
public void addNested(User1 user){
user1Mapper.insert(user);
}
}复制代码
User2Service方法:
@Service
public class User2ServiceImpl implements User2Service {
//省略其余...
@Override
@Transactional(propagation = Propagation.NESTED)
public void addNested(User2 user){
user2Mapper.insert(user);
}
@Override
@Transactional(propagation = Propagation.NESTED)
public void addNestedException(User2 user){
user2Mapper.insert(user);
throw new RuntimeException();
}
}复制代码
此场景外围方法没有开启事务。
验证方法1:
@Override
public void notransaction_exception_nested_nested(){
User1 user1=new User1();
user1.setName("张三");
user1Service.addNested(user1);
User2 user2=new User2();
user2.setName("李四");
user2Service.addNested(user2);
throw new RuntimeException();
}复制代码
验证方法2:
@Override
public void notransaction_nested_nested_exception(){
User1 user1=new User1();
user1.setName("张三");
user1Service.addNested(user1);
User2 user2=new User2();
user2.setName("李四");
user2Service.addNestedException(user2);
}复制代码
分别执行验证方法,结果:
验证方法序号 | 数据库结果 | 结果分析 |
---|---|---|
1 | “张三”、“李四”均插入。 | 外围方法未开启事务,插入“张三”、“李四”方法在本身的事务中独立运行,外围方法异常不影响内部插入“张三”、“李四”方法独立的事务。 |
2 | “张三”插入,“李四”未插入。 | 外围方法没有事务,插入“张三”、“李四”方法都在本身的事务中独立运行,因此插入“李四”方法抛出异常只会回滚插入“李四”方法,插入“张三”方法不受影响。 |
结论:经过这两个方法咱们证实了在外围方法未开启事务的状况下Propagation.NESTED
和Propagation.REQUIRED
做用相同,修饰的内部方法都会新开启本身的事务,且开启的事务相互独立,互不干扰。
外围方法开启事务。
验证方法1:
@Transactional
@Override
public void transaction_exception_nested_nested(){
User1 user1=new User1();
user1.setName("张三");
user1Service.addNested(user1);
User2 user2=new User2();
user2.setName("李四");
user2Service.addNested(user2);
throw new RuntimeException();
}复制代码
验证方法2:
@Transactional
@Override
public void transaction_nested_nested_exception(){
User1 user1=new User1();
user1.setName("张三");
user1Service.addNested(user1);
User2 user2=new User2();
user2.setName("李四");
user2Service.addNestedException(user2);
}复制代码
验证方法3:
@Transactional
@Override
public void transaction_nested_nested_exception_try(){
User1 user1=new User1();
user1.setName("张三");
user1Service.addNested(user1);
User2 user2=new User2();
user2.setName("李四");
try {
user2Service.addNestedException(user2);
} catch (Exception e) {
System.out.println("方法回滚");
}
}复制代码
分别执行验证方法,结果:
验证方法序号 | 数据库结果 | 结果分析 |
---|---|---|
1 | “张三”、“李四”均未插入。 | 外围方法开启事务,内部事务为外围事务的子事务,外围方法回滚,内部方法也要回滚。 |
2 | “张三”、“李四”均未插入。 | 外围方法开启事务,内部事务为外围事务的子事务,内部方法抛出异常回滚,且外围方法感知异常导致总体事务回滚。 |
3 | “张三”插入、“李四”未插入。 | 外围方法开启事务,内部事务为外围事务的子事务,插入“张三”内部方法抛出异常,能够单独对子事务回滚。 |
结论:以上试验结果咱们证实在外围方法开启事务的状况下Propagation.NESTED
修饰的内部方法属于外部事务的子事务,外围主事务回滚,子事务必定回滚,而内部子事务能够单独回滚而不影响外围主事务和其余子事务
由“1.2 场景二”和“3.2 场景二”对比,咱们可知:
NESTED和REQUIRED修饰的内部方法都属于外围方法事务,若是外围方法抛出异常,这两种方法的事务都会被回滚。可是REQUIRED是加入外围方法事务,因此和外围事务同属于一个事务,一旦REQUIRED事务抛出异常被回滚,外围方法事务也将被回滚。而NESTED是外围方法的子事务,有单独的保存点,因此NESTED方法抛出异常被回滚,不会影响到外围方法的事务。
由“2.2 场景二”和“3.2 场景二”对比,咱们可知:
NESTED和REQUIRES_NEW均可以作到内部方法事务回滚而不影响外围方法事务。可是由于NESTED是嵌套事务,因此外围方法回滚以后,做为外围方法事务的子事务也会被回滚。而REQUIRES_NEW是经过开启新的事务实现的,内部事务和外围事务是两个事务,外围事务回滚不会影响内部事务。
鉴于文章篇幅问题,其余事务传播行为的测试就不在此一一描述了,感兴趣的读者能够去源码中本身寻找相应测试代码和结果解释。传送门:github.com/TmTse/tran…
介绍了这么多事务传播行为,咱们在实际工做中如何应用呢?下面我来举一个示例:
假设咱们有一个注册的方法,方法中调用添加积分的方法,若是咱们但愿添加积分不会影响注册流程(即添加积分执行失败回滚不能使注册方法也回滚),咱们会这样写:
@Service
public class UserServiceImpl implements UserService {
@Transactional
public void register(User user){
try {
membershipPointService.addPoint(Point point);
} catch (Exception e) {
//省略...
}
//省略...
}
//省略...
}复制代码
咱们还规定注册失败要影响addPoint()
方法(注册方法回滚添加积分方法也须要回滚),那么addPoint()
方法就须要这样实现:
@Service
public class MembershipPointServiceImpl implements MembershipPointService{
@Transactional(propagation = Propagation.NESTED)
public void addPoint(Point point){
try {
recordService.addRecord(Record record);
} catch (Exception e) {
//省略...
}
//省略...
}
//省略...
}复制代码
咱们注意到了在addPoint()
中还调用了addRecord()
方法,这个方法用来记录日志。他的实现以下:
@Service
public class RecordServiceImpl implements RecordService{
@Transactional(propagation = Propagation.NOT_SUPPORTED)
public void addRecord(Record record){
//省略...
}
//省略...
}复制代码
咱们注意到addRecord()
方法中propagation = Propagation.NOT_SUPPORTED
,由于对于日志无所谓精确,能够多一条也能够少一条,因此addRecord()
方法自己和外围addPoint()
方法抛出异常都不会使addRecord()
方法回滚,而且addRecord()
方法抛出异常也不会影响外围addPoint()
方法的执行。
经过这个例子相信你们对事务传播行为的使用有了更加直观的认识,经过各类属性的组合确实能让咱们的业务实现更加灵活多样。
经过上面的介绍,相信你们对Spring事务传播行为有了更加深刻的理解,但愿你们平常开发工做有所帮助。