众所周知,代理对象时,例如为Spring / EJB创建具有事务属性的Bean时,甚至当您使用某些框架创建部分模拟时,代理对象都不知道,内部调用也不会重定向,然后也没有被拦截…
这就是为什么如果您在Spring中做类似的事情:
@Transactionnal public void doSomething() { doSomethingInNewTransaction(); doSomethingInNewTransaction(); doSomethingInNewTransaction(); } @Transactional(propagation = Propagation.REQUIRES_NEW) public void doSomethingInNewTransaction() { ... }
当您致电doSomething时,您希望除了主要交易外还有3个新交易,但是实际上,由于这个问题,您只会得到一个新交易…
所以我想知道您如何处理此类问题…
实际上,我处于必须处理复杂的交易系统的情况,并且没有比将我的服务拆分为许多小型服务更好的方法了,因此我肯定会通过所有代理…
这让我很困扰,因为所有代码都属于同一个功能域,不应拆分。
RobH说,我们可以将spring代理注入服务中,然后调用proxy.doSomethingInNewTransaction();。代替。这很容易做到并且有效,但是我真的不喜欢它。
侯云峰这样说:
因此,我编写了自己的CglibSubclassingInstantiationStrategy版本和代理创建器,以便它将使用CGLIB生成一个真正的子类,该子类将调用委托给其父类而不是Spring正在进行的另一个实例。因此,我可以随意注释任何方法(只要它不是私有的),无论我从哪里调用这些方法,都将得到照顾。好吧,我仍然要付出代价:1.我必须列出要启用新的CGLIB子类创建的所有注释。2.由于我现在正在生成子类,因此无法注释final方法,因此无法截获final方法。
他所说的“现在正在春天”是什么意思?这是否意味着现在就拦截了内部事务调用?
您认为哪个更好?
当您需要某种事务粒度时,您是否拆分班级?还是您使用上述类似的解决方法?(请分享)
我将讨论Spring和@Transactional,但该建议也适用于许多其他框架。
这是基于代理的方面的固有问题。在spring文档中对此进行了讨论:
http://static.springsource.org/spring/docs/3.0.x/spring-framework- reference/html/aop.html#aop-understanding-aop- proxies
有许多可能的解决方案。
重构类,以避免绕过代理的自调用。
Spring文档将其描述为 “最佳方法(此处最好使用术语“最佳”)” 。
这种方法的优点是它的简单性,并且与任何框架都没有关系。但是,这可能不适用于事务性很强的代码库,因为您最终会遇到许多琐碎的小类。
在类内部获取对代理的引用。
这可以通过注入代理或使用硬编码的“AopContext.currentProxy()”调用来完成(请参见上面的Spring文档。)。
该方法使您避免拆分类,但是在许多方面都抵消了使用事务注释的优势。我个人认为这是有些丑陋的事情之一,但丑陋是自给自足的,如果使用大量交易,这可能是实用的方法。
切换到使用AspectJ
由于AspectJ不使用代理,因此自调用不是问题
但是,这是一种非常干净的方法-以引入另一个框架为代价。由于这个原因,我从事了一个大型项目,其中引入了AspectJ。
根本不要使用@Transactional
重构代码以使用手动事务划分-可能使用装饰器模式。
一种选择-但是需要适度的重构,引入额外的框架联系和增加的复杂性-因此可能不是首选
我的建议
通常,拆分代码是最好的答案,对于分离关注点也可能是一件好事。但是,如果我有一个严重依赖嵌套事务的框架/应用程序,我会考虑使用AspectJ允许自调用。