因为2020年的疫情,公司就一直不景气,从2020年10月起,公司就开始只发80%工资,从今年2月份开始宣布“暂时”只发60%工资,或选择自愿离职,之前没发的“择日发放”,当时就挺犹豫的,已经积累了4个月的20%还没发,也是一笔不算少的收入,如果离职了,还不知道什么时候才能发下来,而且目前的大环境也不是很好,手里的项目也一时半会交不出去,听主管说公司的账上还有几千万,也在谈新的外包项目,是有转机的,于是选择了接收60%工资,结果还没坚持到5月份,公司就直接宣布破产,好在老板还不错,社保一直也没断,最后还给我们补了钱,算了一下,差不多之前没发的工资都补上了。
虽然工资都拿到手了,不过也没工作了,前公司的主管帮我推荐了一份工作,我前天就去面试了,面试之前还是很有信心的,一来,是熟人推荐,二来,我自己也有2年多的工作经验了,结果,没想到被一个我认为非常简单的题目给问倒了,这个题目是这样的:“在某个业务类中有2个更新数据的方法,且都是事务性的,如果第2个方法调用第1个方法,会有几个事务?”,如果把文字转换为成代码,大致就是这样的:
public class UserService {
@Transactional
public void update1() {
// 执行某些操作
}
@Transactional
public void update2() {
update1(); // 调用当前类中另一个事务性的方法
}
}
这明显考察的是事务的传播!老实说,虽然我有2年多的工作经验,但公司的规模也不大,参与的项目中也没有太复杂的事务,一般都是在需要事务性的业务方法上加@Transactional
注解就完事了,只要测试结果没问题,一直没有纠结过事务的传播类型,好在面试的前一天晚上翻了翻当年培训时老师给的笔记,顺利的答了出来,事务的传播类型有这几种:
MANDATORY
NEVER
NOT_SUPPORTED
SUPPORTS
REQUIRED
(默认)REQUIRES_NEW
NESTED
所以,这个面试题的答案就是:“2个事务性的方法,一个调用另一个,由于事务传播的默认值是REQUIRED
,则表现为:如果当前无事务,则创建,如果当前有事务,则使用”,为了完善我的答案,我还继续补充了:“如果将@Transactional
注解的propagation
属性配置为其它值,则会不同”。当我非常流利的把我脑中的答案说完之后,面试官笑了笑,说了两个字:“不对”,我当时就懵了,最后,面试官也没有告诉我答案,只是让我自己回去找答案……不过运气还算不错,由于只错了这一题,最后还是顺利入职了。
我觉得每个码农对技术都是有一定的执着的,前天面试完后,自己也上网看了一些文章,大多都只说了事务的传播类型,及各种类型的表现,根本没有我想要的答案,于是,昨天我联系了一下当年培训时的苍老师,他听了题目和我的答案后,也是“呵呵”一笑,说这是Spring认证考试中的原题,被考到这一题的概率至少有70%,而且,最近好多公司都直接拿Spring题库里的题当面试题……然后他就让我等着,过一会给我发了个压缩包,是一份Demo代码,果然是人狠话不多,直接拿代码讲道理,我看了看代码,按照苍老师在代码里留的注释改动了几下,基本上就有答案了!
虽然答案本身很简单,但是又领悟了不少东西,为了“纪念”一下这个错题,和大家分享一下Spring中@Transactional
的细节!
首先,项目结构是这样的:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dUHU8fy8-1625739285294)(image-20210630170414935.png)]
这个项目中主要用到了Spring、Mybatis和单元测试,比较基础的环境搭建和配置就不说了,如果需要这个代码的,可以从 http:// 下载。
大概就是:项目中使用了t_user
和t_order
这2张表,且都有几条初始数据,在这2张表对应的持久层都编写了根据id修改数据的功能。
重点是业务部分,我们都知道,事务是在业务层进行管理的,业务层的结构是这样的(暂时不用的先不贴出来):
[src]
[main]
[java]
[cn.tedu]
[service]
[impl]
UserServiceImpl
UserService
很显然,以User
前缀开头的都是处理t_user
表的数据的,在最初的实验中只需要观察这1张表就可以了。
关于UserService
接口:
package cn.tedu.service;
public interface UserService {
void update1();
void update2();
}
关于UserServiceImpl
类:
package cn.tedu.service.impl;
import cn.tedu.mapper.UserMapper;
import cn.tedu.service.OrderService;
import cn.tedu.service.UserService;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
@Service
public class UserServiceImpl implements UserService {
private UserMapper userMapper;
private OrderService orderService;
public UserServiceImpl(UserMapper userMapper, OrderService orderService) {
this.userMapper = userMapper;
this.orderService = orderService;
}
// TODO-01:调整是否使用以下@Transactional注解,并运行单元测试,以观察效果
// @Transactional
public void update1() {
int rows;
// 更新id=1的数据,会成功
rows = userMapper.updateUserNameById(1, "USER-1000001");
if (rows != 1) {
throw new RuntimeException("更新User:id=1数据失败!");
}
// 更新id=1000000,会失败
rows = userMapper.updateUserNameById(1000000, "USER-1000001");
if (rows != 1) {
throw new RuntimeException("更新User:id=1000000数据失败!");
}
}
// TODO-02:调整是否使用以下@Transactional注解,并运行单元测试,以观察效果
@Transactional
public void update2() {
update1();
}
}
可以看到,以上update1()
方法中有2次更新操作,第1次肯定会成功的,第2次则会因为id值不存在而失败,失败后抛出了RuntimeException
对象,符合Spring管理事务的默认回滚规则,但是,update1()
方法不一定有@Transactional
注解,这是苍老师留着我自己测试效果的,下面的update2()
就比较简单了,它直接调用了update1()
方法。
苍老师写的测试也非常有趣,使用了@Sql
注解处理初始化数据库与数据,使用了断言,和我们平时偷懒写的完全不同,那天我也问过他,他说Spring认证考试也会考这个,以后搞不好也会成为用人单位的面试题(毕竟有不少用人单位都是直接上网百度找面试题,根本不自己出错,大家都懂的)……他是这么写的:
package cn.tedu.service;
import cn.tedu.config.ApplicationConfig;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.jdbc.Sql;
import org.springframework.test.context.jdbc.SqlConfig;
import org.springframework.test.context.junit.jupiter.SpringJUnitConfig;
import static org.junit.jupiter.api.Assertions.assertThrows;
@SpringJUnitConfig(ApplicationConfig.class)
@Sql(config = @SqlConfig(dataSource = "dataSource"),
scripts = {"classpath:/sql/schema.sql", "classpath:/sql/data.sql"})
public class UserServiceTests {
@Autowired
UserService userService;
@Test
public void testUpdate1() {
assertThrows(RuntimeException.class, () -> {
userService.update1();
});
}
@Test
public void testUpdate2() {
assertThrows(RuntimeException.class, () -> {
userService.update2();
});
}
}
其实,现在就可以测试出效果了,根据在业务类中的2个方法上是否使用@Transactional
注解,观察数据是否回滚即可判断,我测试的结果如下:
是否在update1() 上使用注解 | 是否在update2() 上使用注解 | 是否回滚 |
---|---|---|
是 | 是 | 是 |
否 | 是 | 是 |
是 | 否 | 否 |
否 | 否 | 否 |
可以看到,事务是否回滚完全取决于update2()
方法有没有@Transactional
注解,与update1()
方法是否有注解无关!
苍老师说,Spring官方给出的文档中明确指出:Propagation Rules Are Enforced by a Proxy,即“传播规则是由代理强制执行的”。所以,Spring管理事务是基于接口进行代理的,在调用@Transactional
注解的方法之前就会开启事务,并在过程中决定是否回滚或最终提交!
在以上代码中,由于update1()
是在update2()
内部调用的,不是由代理对象来调用的,所以,执行update2()
方法的过程大致上是:
开启事务
执行update2()方法
调用update1()方法
因update1()方法抛出异常且符合回滚规则,执行回滚事务
若未出现回滚,则提交事务(本例会回滚,不会执行这一步)
所以,回到我面试的那个题目,正确的答案应该是:只会在调用update2()
方法时开启1个事务,内部调用的update1()
根本不是事务性的(不管有没有@Transactional
注解),既然只有1个事务,也就不存在事务的传播了!
其实,到这里,我的问题已经解决了,但是苍老师还帮我写好了后续的Demo代码,让我更深刻的理解,这可能就是老师的职业病吧,要么不讲,要讲就一讲到底。
接下来就要涉及更新t_order
表的数据了,对应的业务接口和业务实现类分别是OrderService
和OrderServiceImpl
,关于OrderService
接口:
package cn.tedu.service;
public interface OrderService {
void updateSuccessfully();
}
关于OrderServiceImpl
类:
package cn.tedu.service.impl;
import cn.tedu.mapper.OrderMapper;
import cn.tedu.service.OrderService;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Propagation;
import org.springframework.transaction.annotation.Transactional;
@Service
public class OrderServiceImpl implements OrderService {
private OrderMapper orderMapper;
public OrderServiceImpl(OrderMapper orderMapper) {
this.orderMapper = orderMapper;
}
// TODO-08:直接运行单元测试,以观察效果
// TODO-09:启用以下@Transactional注解,并运行单元测试,以观察效果
// TODO-10:启用以下注解的参数,并运行单元测试,以观察效果
// @Transactional //(propagation = Propagation.REQUIRES_NEW)
public void updateSuccessfully() {
// 更新id=1的数据,会成功
int rows;
rows = orderMapper.updateNumberById(1, 1000000);
if (rows != 1) {
throw new RuntimeException("更新Order:id=1数据失败!");
}
}
}
显然以上业务非常简单,就是成功的更新某条数据,在方法之前预先写好了注解和参数,稍后进行调节以观察效果。
另外,在UserServiceImpl
类的update2()
方法中,根据老师留下的注释调整后,有效代码为:
@Transactional
public void update2() {
// 更新id=2的数据,会成功
int rows;
rows = userMapper.updateUserNameById(2, "USER-1000002");
if (rows != 1) {
throw new RuntimeException("更新id=2数据失败!");
}
// 调用另一个业务对象的更新方法
orderService.updateSuccessfully();
// 更新id=2000000的数据,会失败
rows = userMapper.updateUserNameById(2000000, "USER-1000002");
if (rows != 1) {
throw new RuntimeException("更新id=2000000数据失败!");
}
}
所以,此时调用以上update2()
方法,过程会是:
更新id=2的数据,会成功
调用另一个业务对象的更新方法,会成功
更新id=2000000的数据,会失败
几次测试下来,结果如下:
OrderServiceImpl 的updateSuccessfully() 方法上的注解状态 | 回滚状态 |
---|---|
无注解 | 完全回滚 |
@Transactional | 完全回滚 |
@Transactional(propagation = Propagation.REQUIRES_NEW) | t_user 表回滚,t_order 表已提交 |
可以看到以上最后一次使用@Transactional(propagation = Propagation.REQUIRES_NEW)
时,OrderServiceImpl
中的updateSuccessfully()
方法是运行在一个新的事务(配置的注解参数决定的)上的,由于这个updateSuccessfully()
方法运行没有出错,就直接提交了,而UserServiceImpl
中的update2()
因为最后尝试更新id=2000000的数据会失败导致了回滚,所以就出现了t_user
表回滚了,而t_order
表提交了的现象,也就体现了事务的传播!
这一次也是在update2()
中调用另一个事务性的方法,为什么就是有效的呢?是因为这次调用的是另一个对象的方法,而这个对象也是Spring的事务管理机制产生的代理对象,其执行过程大致是:
开启事务
执行update2()方法(UserServiceImpl类的)
更新id=2的数据,且成功
开启新事务
调用updateSuccessfully()方法(OrderServiceImpl类的)
未出现回滚,则提交事务
更新id=2000000的数据,且失败,执行回滚事务
若未出现回滚,则提交事务(本例会回滚,不会执行这一步)
最后,苍老师还给我留了个TODO-Final
,代码很简单,就是在update2()
方法里输出了一下orderService
的类名:
// TODO-Final:启用接下来的这行代码,并运行单元测试,以观察效果
System.out.println(orderService.getClass());
然后,在控制台就可以清楚的看到这个代理对象:
class com.sun.proxy.$Proxy37
注意:不能只输出orderService
,必须是orderService.getClass()
,因为代理对象重写了toString()
方法,如果没有调用getClass()
的话,看到的就会是cn.tedu.service.impl.OrderServiceImpl@5f7b97da
,你就看不出它是个代理对象了,这个家伙是不是很狡猾?
通过这个Demo,可以总结出这几点:
- Spring管理事务是基于接口代理的;
- 当前类的方法之间的调用,并不存在事务的传播,被调用的方法之前是否添加
@Transactional
注解对结果没有影响; - 不同类的方法之间的调用,对于被调用的方法,可以通过
@Transactional
注解的propagation
属性来配置事务传播类型。
另外,还有个附加的收获,以前每次写业务层代码的时候,都是先写业务接口,再写实现类,为什么要有业务接口呢?一直以来我也没有深究过这个问题,只当是一种开发规范来遵守,现在看来意义不仅于此!
在执行单元测试的时候,我还故意的试了一下,如果将业务对象声明为UserServiceImpl
这种类型,启动过程中就会提示自动装配失败,项目根本无法运行,必须声明成UserService
这样的接口类型,另外,如果声明为UserServiceImpl
类型,只要全程没有@Transactional
注解,启动项目并不会报错,至于道理嘛,相信大家已经猜到了,我就不解释了。
如看了篇文章,觉得很有用,推荐给大家。
转发:https://blog.csdn.net/javaxd/article/details/118563164