【不懂就问】SpringFramework中的注解声明式事务怎么被Shiro搞失效了
【“不懂就问”,是一个新的系列,主要整理我的小册群里遇到的一些比较有意思的 / 有难度的 / 容易被讨论起来的问题,并给出问题的解析和方案等等。喜欢的小伙伴们可以点赞关注我鸭 ~ ~ 学习源码可以看看我的小册 ~ ~】
近期我在 SpringBoot 的小册交流群里碰见一个问题,感觉蛮有意思的,拿出来跟小伙伴们分享一下。
原问题
那位小伙伴的项目中,有一部分 Service 的注解事务一直不起作用,但也只是一部分起作用,也有一部分是好的。而且更奇怪的是,如果他把一个事务不起作用的 ServiceImpl 代码完整的抄一遍到新的复制类里头,那个类居然是有事务的!
初步分析
咱回想一下,按常理来讲,SpringFramework 中的事务不生效,大概有这么几种情况:
@Transactional
注解标注在非 public 方法上@Transactional
注解标注在接口上,但实现类使用 Cglib 代理@Transactional
注解标注抛出Exception
,默认不捕捉- service 方法中自行
try-catch
了异常但没有再抛出RuntimeException
- 原生 SSM 开发中,父子容器一起包扫描,会导致子容器先扫描到 service 并注册到子容器中但不加载事务,之后虽然父容器也扫描到 service 但因为子容器中的 controller 已经注入了没有事务代理的 service ,会导致事务失效
- 声明式事务的配置必须由父 IOC 容器加载,SpringWebMvc 的子 IOC 容器加载不生效
除此之外,如果使用的关系型数据库是 MySQL ,还要关注是否为 InnoDB 引擎( MyISAM 不支持事务)。
结果小伙伴一通分析,发现这上面罗列的情况都没有出现,排查难度进一步加大。
新的关注点
隔了大概半天吧,那位小伙伴突然发现了一点问题:他们的项目使用了 Shiro 作为权限校验框架,而且那些事务失效的 Service 刚好就是被 Shiro 中自定义 Realm 依赖的 Service !有了这个线索,下面排查起来就容易一些了。
问题复现
咱也自己搞一套,看看是不是像他说的那样吧!
工程搭建
为了快速复现这个问题,咱使用 SpringBoot + shiro-spring-boot-web-starter
构建。( SpringBoot 版本只要在 2.x 就可以,本文测试功能选用 2.2.8 )
pom
关键的依赖有下面 4 个:
1 | <dependency> |
2 | <groupId>org.springframework.boot</groupId> |
3 | <artifactId>spring-boot-starter-web</artifactId> |
4 | </dependency> |
5 | |
6 | <dependency> |
7 | <groupId>org.springframework.boot</groupId> |
8 | <artifactId>spring-boot-starter-jdbc</artifactId> |
9 | </dependency> |
10 | <dependency> |
11 | <groupId>org.apache.shiro</groupId> |
12 | <artifactId>shiro-spring-boot-web-starter</artifactId> |
13 | <version>1.5.3</version> |
14 | </dependency> |
15 | |
16 | <dependency> |
17 | <groupId>com.h2database</groupId> |
18 | <artifactId>h2</artifactId> |
19 | <version>1.4.199</version> |
20 | </dependency> |
Realm
Shiro 的自定义策略核心就是 Realm
,咱也不整那些花里胡哨的,直接糊弄下算了。
1 | public class CustomRealm extends AuthorizingRealm { |
2 | |
3 | |
4 | protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException { |
5 | if (token.getPrincipal() == null) { |
6 | return null; |
7 | } |
8 | String name = token.getPrincipal().toString(); |
9 | // 请求数据库查询是否存在用户,这里省略 |
10 | return new SimpleAuthenticationInfo(name, "123456", getName()); |
11 | } |
12 | |
13 | |
14 | protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) { |
15 | SimpleAuthorizationInfo authorizationInfo = new SimpleAuthorizationInfo(); |
16 | // 请求数据库/缓存加载用户的权限,这里暂时使用一组假数据 |
17 | authorizationInfo.addStringPermissions(Arrays.asList("aa", "bb", "cc")); |
18 | return authorizationInfo; |
19 | } |
20 | } |
配置类
只声明 Realm 还不够,需要定义几个 Bean 来补充必需的组件才行。
1 |
|
2 | public class ShiroConfiguration { |
3 | |
4 | // 自定义Realm注册 |
5 | |
6 | public CustomRealm authorizer() { |
7 | return new CustomRealm(); |
8 | } |
9 | |
10 | // 动态代理创建器(上面没有导入AOP) |
11 | |
12 | public DefaultAdvisorAutoProxyCreator advisorAutoProxyCreator() { |
13 | DefaultAdvisorAutoProxyCreator advisorAutoProxyCreator = new DefaultAdvisorAutoProxyCreator(); |
14 | advisorAutoProxyCreator.setProxyTargetClass(true); |
15 | return advisorAutoProxyCreator; |
16 | } |
17 | |
18 | // 过滤器定义,此处选择全部放行,方便调试 |
19 | |
20 | public ShiroFilterChainDefinition filterChainDefinition() { |
21 | DefaultShiroFilterChainDefinition filterChainDefinition = new DefaultShiroFilterChainDefinition(); |
22 | filterChainDefinition.addPathDefinition("/**", "anon"); |
23 | return filterChainDefinition; |
24 | } |
25 | } |
数据库配置
快速搭建临时测试的、结构很简单的数据库,选择 h2 内存数据库更为合适。
application.properties
中配置 h2 的数据源及初始化数据库的 SQL :
1 | org.h2.Driver = |
2 | jdbc:h2:mem:shiro-test = |
3 | sa = |
4 | sa = |
5 | h2 = |
6 | |
7 | classpath:sql/schema.sql = |
8 | classpath:sql/data.sql = |
9 | |
10 | true = |
11 | /h2 = |
12 | true = |
resources
目录下创建 sql 文件夹,并创建两个 .sql 文件,分别声明数据库表的结构和数据:
1 | create table if not exists sys_department ( |
2 | id varchar(32) not null primary key, |
3 | name varchar(32) not null |
4 | ); |
5 | |
6 | --- |
7 | |
8 | insert into sys_department (id, name) values ('idaaa', 'testaaa'); |
9 | insert into sys_department (id, name) values ('idbbb', 'testbbb'); |
10 | insert into sys_department (id, name) values ('idccc', 'testccc'); |
11 | insert into sys_department (id, name) values ('idddd', 'testddd'); |
编写测试代码
下面就可以按照三层架构来写一些很简单的测试代码了。
DemoDao
这里咱就不整合 MyBatis / Hibernate 了,直接使用原生的 JdbcTemplate
就可以:
1 |
|
2 | public class DemoDao { |
3 | |
4 | |
5 | JdbcTemplate jdbcTemplate; |
6 | |
7 | public List<Map<String, Object>> findAll() { |
8 | return jdbcTemplate.query("select * from sys_department", new ColumnMapRowMapper()); |
9 | } |
10 | |
11 | public int save(String name) { |
12 | return jdbcTemplate.update("insert into sys_department (id, name) values (?, ?)", |
13 | UUID.randomUUID().toString().replaceAll("-", ""), name); |
14 | } |
15 | |
16 | public int update(String id, String name) { |
17 | return jdbcTemplate.update("update sys_department set name = ? where id = ?", name, id); |
18 | } |
19 | } |
DemoService + DemoService2
声明一个会触发抛出运行时异常的方法,并标注 @Transactional
注解:
1 |
|
2 | public class DemoService { |
3 | |
4 | |
5 | DemoDao demoDao; |
6 | |
7 | .class) (rollbackFor = Exception |
8 | public void doTransaction() { |
9 | demoDao.save("aaaaaaaa"); |
10 | int i = 1 / 0; |
11 | demoDao.update("18", "ccc"); |
12 | } |
13 | } |
DemoService2
同样的代码,仅仅是类名不同,代码不再贴出。
DemoController
Controller 里面同时依赖这两个 Service :
1 |
|
2 | public class DemoController { |
3 | |
4 | |
5 | DemoService demoService; |
6 | |
7 | |
8 | DemoService2 demoService2; |
9 | |
10 | "/doTransaction") ( |
11 | public String doTransaction() { |
12 | demoService.doTransaction(); |
13 | return "doTransaction"; |
14 | } |
15 | |
16 | "/doTransaction2") ( |
17 | public String doTransaction2() { |
18 | demoService2.doTransaction(); |
19 | return "doTransaction2"; |
20 | } |
21 | } |
Realm依赖Service
最后,让自定义的 Realm 依赖咱刚写的 DemoService
:
1 | public class CustomRealm extends AuthorizingRealm { |
2 | |
3 | |
4 | DemoService demoService; |
5 | // ...... |
运行测试
运行 SpringBoot 的主启动类,在浏览器输入 http://localhost:8080/h2
输入刚才在 properties 文件中声明的配置,即可打开 h2 数据库的管理台。
执行 SELECT * FROM SYS_DEPARTMENT
,可以发现数据已经成功初始化了:
下面测试事务,在浏览器输入 localhost:8080/doTransaction
,浏览器自然会报除零异常,但刷新数据库,会发现数据库真的多了一条 insert 过去的数据!请求 /doTransaction2
则不会插入新的数据。
到这里,问题就真的发生了,下面要想办法解决这个问题才行。
问题排查
既然两个 Service 在代码上完全一致,只是一个被 Realm 依赖了,一个没有依赖而已,那总不能是这两个 Service 本来就不一样吧!
检查两个Service对象
将断点打在 /doTransaction
对应的方法上,Debug 重新启动工程,待断点落下后,发现被 Realm 依赖的 DemoService
不是代理对象,而没有被 Realm 依赖的 DemoService2
经过事务的增强,成为了一个代理对象:
所以由此就可以看到问题所在了吧!上面的那个 DemoService
都没经过事务代理,凭什么能支持事务呢???
检查Service的创建时机
既然两个 Service 都不是一个样的,那咱就看看这俩对象都啥时候创建的吧!给 DemoService
上显式的添加上无参构造方法,方便过会 Debug :
1 |
|
2 | public class DemoService { |
3 | |
4 | public DemoService() { |
5 | System.out.println("DemoService constructor run ......"); |
6 | } |
重新以 Debug 运行,等断点打在构造方法中,观察方法调用栈:
看上去还比较正常吧,但如果往下拉到底,这问题就太严重了:
哦,合着我这个 DemoService
在 refresh
方法的后置处理器注册步骤就已经创建好了啊!小伙伴们要知道,SpringFramework 中 ApplicationContext
的初始化流程,一定是先把后置处理器都注册好了,再创建单实例 Bean 。但是这里很明显是后置处理器还没完全处理完,就引发单实例 Bean 的创建了!
问题解决
问题终于找明白了,咋解决呢?其实网上有的是现成的文章了:
spring + shiro 配置中部分事务失效分析及解决方案
总的来看,解决方案的核心在于:如何让 Realm
创建时不立即依赖创建 DemoService
,所以就有两种解决方案了:要么延迟初始化 DemoService
,要么把自定义的 Realm
和 SecurityManager
放在一个额外的空间,利用监听器机制创建它们 。具体的实现可以参照上面文章的写法,这里就不赘述了。
原理扩展
解决问题之后,如果能从这里面了解到一点更深入的原理知识,想必那是最好不过了。下面就这个问题出现的原因,以及上面 @Lazy
方案的原理,咱都深入解析一下。
Shiro提早创建Realm的原因
既然上面看到了方法调用栈中,DemoService
被自定义 Realm
依赖后在 ApplicationContext
的 refresh
阶段的 registerBeanPostProcessors
中就已经被触发创建,可它为什么非要搞这一出呢?自定义 Realm
放到 finishBeanFactoryInitialization
中统一创建不好吗?下面咱通过 Debug 研究问题的成因。
Debug运行
DemoService
中的断点不要去掉,重新 Debug 让断点停在那里,翻到最底下的调用栈,查看那个正在创建的 BeanPostProcessor
,发现它的名称是 shiroEventBusAwareBeanPostProcessor
:
Shiro的后置处理器创建
翻开创建 shiroEventBusAwareBeanPostProcessor
的位置,在 ShiroBeanAutoConfiguration
中,它又依赖了一个 EventBus
:
1 |
|
2 |
|
3 |
|
4 | public ShiroEventBusBeanPostProcessor shiroEventBusAwareBeanPostProcessor() { |
5 | return super.shiroEventBusAwareBeanPostProcessor(); |
6 | } |
7 | |
8 | protected ShiroEventBusBeanPostProcessor shiroEventBusAwareBeanPostProcessor() { |
9 | return new ShiroEventBusBeanPostProcessor(eventBus()); |
10 | } |
顺着方法调用栈往上爬,找到下一个 doCreateBean
,发现确实有创建 eventBus
的部分:
再往上爬,发现这上面有一个 wrapIfNecessary
方法的调用,很明显这是要搞 AOP 增强了啊:
AOP 的增强需要先获取到增强器,继续往上爬方法调用,在 findAdvisorBeans
方法中找到了两个适配的增强器:
上面的是 Shiro 的授权相关的增强器,下面是 SpringFramework 中的事务控制增强器。
触发AOP增强器的创建
根据迭代顺序,先取出下面的事务控制增强器 TransactionAdvisor
,由于获取到增强器的 Bean 也是需要走统一的 getBean
方法,所以在方法调用栈中,咱又一次看到了 getBean
方法,继续往下创建。
由于在 SpringFramework 中,使用 @Configuration
+ @Bean
声明的 Bean ,都是要先把配置类初始化好,才能创建 Bean 。所以继续往上爬调用栈时,会发现它并没有接着创建 Shiro 的增强器 authorizationAttributeSourceAdvisor
,而是先初始化了声明有 TransactionAttributeSourceAdvisor
的配置类 ProxyTransactionManagementConfiguration
:
再往上走,发现又出现了一次 wrapIfNecessary
方法,说明配置类也会被 AOP 增强。那就重复一遍上面的步骤,继续遇到这两个增强器。
这个时候可能有小伙伴产生疑问了:这次创建就是因为上面的 TransactionAttributeSourceAdvisor
创建才跟过来的,这次还要再创建,这是闹哪出呢?放心,咱都想到这个问题了,人家写 SpringFramework 的大佬们能想不到吗?所以在创建之前,它加了一个判断:
1 | if (this.beanFactory.isCurrentlyInCreation(name)) { |
2 | // 如果当前bean正在创建,则跳过 |
3 | if (logger.isTraceEnabled()) { |
4 | logger.trace("Skipping currently created advisor '" + name + "'"); |
5 | } |
6 | } |
7 | else { |
8 | try { |
9 | advisors.add(this.beanFactory.getBean(name, Advisor.class)); |
10 | } |
这里巧妙的利用了 singletonsCurrentlyInCreation
这个集合,判断了当前增强器是否在创建,这样就不会出现重复创建无限死循环的问题了。
singletonsCurrentlyInCreation
的存放是在getSingleton
方法调用时就已经放进去了,所以能很稳妥的记录下当前正在创建的所有 Bean ,防止死循环重复创建。
Shiro增强器的创建
上面的事务控制增强器跳过去了,那就可以创建 Shiro 的增强器了:
这次没有再出现那些幺蛾子,但是这个增强器本身依赖一个 SecurityManager
:
那就继续创建呗,创建 SecurityManager
的过程中又出现了新的依赖:
这个 authorizer
,就是咱上面在 ShiroConfiguration
中注册的自定义 Realm
。
看到这里了,后续的步骤想必不用我说小伙伴们也能自己想到了吧:Realm 的创建又需要依赖 DemoService
,而 DemoService
在创建时由于事务控制增强器还没有创建好,所以无法代理 DemoService
,最终注入到 Realm 的 DemoService
就是不带事务的。
小结
捋一捋整个流程哈,整个创建过程经历了以下几个层级的依赖创建:
ApplicationContext
的refresh
方法要创建BeanPostProcessor
ShiroEventBusBeanPostProcessor
的创建需要依赖EventBus
EventBus
创建时需要被 AOP 增强,触发 AOP 增强器的创建逻辑此时 AOP 增强器有 2 个,分别是事务控制增强器,和 Shiro 的增强器
首先创建事务控制的 AOP 增强器
TransactionAttributeSourceAdvisor
,由于它定义在配置类中,又触发配置类的创建配置类创建时也要被 AOP 增强,再一次触发 AOP 增强器的创建逻辑
此时事务控制增强器正在被创建,所以被跳过了
触发 Shiro 增强器的创建,而 Shiro 增强器又依赖
SecurityManager
SecurityManager
又依赖authorizer
,也就是自定义的Realm
自定义
Realm
依赖DemoService
,触发DemoService
的创建DemoService
创建后要被事务 AOP 增强,但此时事务控制增强器还没有完全创建好,所以无法代理,导致DemoService
不带事务
@Lazy解决该问题的原理
上面解决方案的第三篇文章,他提到可以用 @Lazy
注解解决问题,我在翻文章时有人说不能用(他把 @Lazy
注解标注到 DemoService
类上了),讲道理可能是他不会用才这么说的( ̄へ ̄)。其实用 @Lazy
注解是完全可行的,不过标注的位置要对,真正要标注的位置是自定义 Realm
的 DemoService
成员上:
1 |
|
2 |
|
3 | DemoService demoService; |
下面咱解释下为什么 @Lazy
标注在自定义 Realm
的依赖上好用,标注在 DemoService
类上不好用。
测试-@Lazy标注在DemoService上
将 @Lazy
注解标注到 DemoService
的类上:
1 |
|
2 |
|
3 | public class DemoService |
重新 Debug ,发现断点落在 DemoService
的构造方法时,refresh
的动作仍然停在 registerBeanPostProcessors
步骤,说明将 @Lazy
标注在 DemoService
上是不可行的,这也就是上面我提的那个文章里说 @Lazy
不可行。
测试-@Lazy标注在自定义Realm的依赖上
去掉上面 DemoService
类上的 @Lazy
,在自定义 Realm
的 DemoService
依赖上标注,重新 Debug,观察断点停下时 refresh
执行的步骤:
可以发现已经到了可以正常初始化单实例 Bean 的时机了,此时创建的 DemoService
就不会有问题了。
放行断点,待应用启动完成后,浏览器再发送 /doTransaction
的请求,发现这次事务已经生效了。
到这里,就验证了 @Lazy
的正确使用方法。
但是!!!不要着急!下面咱再扩展一点原理哈 ~ ~ ~
想一下,此时这个 DemoService
是啥玩意触发创建的?
答案很明显是 DemoController
,因为 Controller 还依赖着 Service 呢。
测试-@Lazy标注Realm+Controller
继续测试,把自定义 Realm
和 DemoController
两个类的 DemoService
依赖都标注上 @Lazy
,重新 Debug ,待断点停下后,想一下此时 DemoService
又是谁触发它创建的呢?
答案也不难猜,是 IOC 容器本身创建的,因为 DemoService
所有被依赖的关系都延迟加载了,但 IOC 容器本身还要预先创建好所有的单实例 Bean ,所以 DemoService
还是在 IOC 容器启动的过程中创建了。
测试-@Lazy全标注
继续,这次把 DemoService
上也标注上 @Lazy
,重新 Debug ,这次应用没有落在断点上直接启动了,说明 IOC 容器本身发现 DemoService
也可以延迟创建,就跳过去了,所以 IOC 容器初始化的全过程中 DemoService
都没有创建。
小结
总结一下 @Lazy
的使用规则和对应的原理:
@Lazy
标注在 Bean 的类上:告诉 IOC 容器,在容器初始化阶段不要实例化我@Lazy
标注在其他 Bean 的依赖上:告诉 IOC 容器,在创建这个标注了@Lazy
的 Bean 时,不要立即处理我标注的这个依赖
本文涉及到的所有源码可以从 GitHub 中找到:https://github.com/LinkedBear/juejin-posts-sources
【都看到这里了,小伙伴们要不要关注点赞一下呀,有源码学习需要的可以看我小册哦,学习起来 ~ 奥利给】
原文作者: LinkedBear
原文链接: http://yoursite.com/2020/06/24/【不懂就问】SpringFramework中的注解声明式事务怎么被Shiro搞失效了/
版权声明: 转载请注明出处(必须保留作者署名及链接)