Seb*_*ber 15 java spring hibernate ejb java-ee
众所周知,当你代理一个对象时,比如当你用Spring/EJB创建一个具有事务属性的bean时,甚至当你用一些框架创建一个局部模拟时,代理对象也不知道,并且内部调用没有被重定向,然后没有截获......
这就是为什么如果你在Spring做类似的事情:
@Transactionnal
public void doSomething() {
doSomethingInNewTransaction();
doSomethingInNewTransaction();
doSomethingInNewTransaction();
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void doSomethingInNewTransaction() {
...
}
当你打电话给doSomething时,除了主要的一个之外,你期望有3个新的交易,但实际上,由于这个问题,你只能得到一个......
所以我想知道你是如何处理这些问题的...
我实际上处在一个我必须处理复杂的事务系统的情况,我没有看到任何比将服务分成许多小服务更好的方法,因此我肯定会通过所有代理...
这让我很困扰,因为所有的代码属于同一个功能域,不应该拆分......
我发现这个相关问题的答案很有趣: Spring - @Transactional - 后台会发生什么？
Rob H说我们可以在服务中注入spring代理,并调用proxy.doSomethingInNewTransaction(); 代替.它很容易做到并且有效,但我真的不喜欢它......
侯云峰说:
所以我编写了自己的CglibSubclassingInstantiationStrategy和代理创建器版本,以便它将使用CGLIB生成一个真正的子类,该子类将调用委托给它的超级而不是另一个实例,Spring现在正在这样做.所以我可以自由地注释任何方法(只要它不是私有的),并且从我称之为这些方法的地方,它们将被处理.好吧,我仍然要付出代价:1.我必须列出我想要启用新CGLIB子类创建的所有注释.2.由于我现在正在生成子类,因此无法对最终方法进行注释,因此无法截获最终方法.
他说"现在哪个春天在做什么"是什么意思？这是否意味着现在拦截了内部交易呼叫？
你觉得哪个更好？
当您需要某些事务粒度时,是否拆分了类？或者你使用上面的一些解决方法？(请分享)
Pab*_*jim 17
我将讨论Spring和@Transactional,但该建议也适用于许多其他框架.
这是基于代理的方面的固有问题.这里的弹簧文档中讨论了它:
有许多可能的解决方案.
重构您的类以避免绕过代理的自调用调用.
Spring文档将其描述为"最好的方法(这里使用松散的术语)".
这种方法的优点是简单,并且与任何框架都没有联系.但是,它可能不适合非常重要的事务性代码库,因为您最终会得到许多非常小的类.
在类的内部获取对代理的引用.
这可以通过注入代理或硬编码的"AopContext.currentProxy()"调用来完成(参见上面的Spring文档).
此方法允许您避免拆分类,但在许多方面否定了使用事务注释的优点.我个人认为,这是有点难看的事情之一,但丑陋是自成一体的,如果使用大量交易,可能是务实的方法.
切换到使用AspectJ
由于AspectJ不使用代理,因此自调用不是问题
这是一个非常干净的方法 - 它是以引入另一个框架为代价的.出于这个原因,我参与了一个大型项目,其中引入了AspectJ.
根本不要使用@Transactional
重构您的代码以使用手动事务划分 - 可能使用装饰器模式.
一个选项 - 但需要适度重构,引入额外的框架关系和增加的复杂性 - 所以可能不是一个首选的选项
我的建议
通常分割代码是最好的答案,也可以是分离问题的好事.但是,如果我有一个严重依赖嵌套事务的框架/应用程序,我会考虑使用AspectJ来允许自我调用.
| 归档时间： |
|
| 查看次数： |
2892 次 |
| 最近记录： |