如何处理Spring / EJB / Mockito代理的内部调用？ [英] How to handle internal calls on Spring/EJB/Mockito... proxies?
问题描述
这就是为什么如果你在Spring中做这样的事情：
@Transactionnal
public void doSomething（）{
doSomethingInNewTransaction（）;
doSomethingInNewTransaction（）;
doSomethingInNewTransaction（）;
}
@Transactional（propagation = Propagation.REQUIRES_NEW）
public void doSomethingInNewTransaction（）{
...
}
当你打电话给doSomething时，除了主要的事情之外，你还会有3个新的交易，但实际上，由于这个问题只有一个...
所以我想知道你如何处理这些问题...
我实际上处于一个我必须处理一个复杂的事务系统的情况，我没有看到比将服务分解成许多小型服务更好的方法，所以我确保通过所有的代理...
这让我很困扰，因为所有的代码都属于同一个功能域，不应该被拆分
我发现这个相关问题有趣的答案：
Spring - @Transactional - Wha t发生在后台？
Rob H说我们可以在服务中注入spring代理，并调用proxy.doSomethingInNewTransaction（）;代替。
这很容易做，它的工作原理，但我不太喜欢...
云峰侯说：
所以我写了我自己的CglibSubclassingInstantiationStrategy版本和
代理创建者，以便它将使用CGLIB生成一个真正的子类
，委托调用它的超级而不是另一个例子，其中
Spring正在做。所以我可以自由地注释任何方法（只要
，因为它不是私人的），从任何我称之为这些方法，他们
将被照顾。嗯，我还是要付出代价：1.我必须列出
所有注释，我想启用新的CGLIB子类
创建。我不能在最终的方法上注释，因为我现在是
生成子类，所以最终的方法不能被拦截。
哪个春天现在在做什么他的意思是什么？这是否意味着内部交易电话现在被截获？
你觉得更好吗？
当您需要一些事务粒度时，您是否拆分了类？
或者你是否使用上面的一些解决方法？ （请分享）
我将谈论Spring和@Transactional，但建议也适用于许多其他框架。 / p>
这是基于代理的方面的固有问题。在这里的春季文档中讨论过：
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/aop.html#aop-理解代理人
有许多可能的解决方案。
重新构造你的类，以避免绕过代理的自调用调用。
Spring文档将其描述为最佳方法最好在这里松散使用）。
这种方法的优点是它的简单性，与任何框架没有联系。然而，它可能不适合一个非常交易的重型代码库，因为你最终会遇到许多小小的课程。
在课程中内部得到一个引用代理。
这可以通过注入代理或使用硬编码的AopContext.currentProxy（）调用来完成（参见上面的Spring文档）。 ）。
此方法允许您避免拆分类，但在许多方面不利于使用事务注释的优点。我个人的意见是，这是一件丑小事，但是丑陋是自足的，如果使用很多交易，可能是务实的做法。
切换到使用AspectJ
由于AspectJ不使用代理，因此自我调用不是问题
虽然这是一个非常干净的方法，但是以引入另一个框架为代价。我已经在一个大型项目中介绍了AspectJ，因为这个原因。
不要使用@Transactional
重新构建您的代码以使用手动事务划分 - 可能使用装饰器模式。
一个选项 - 但需要中等
我的建议
通常分割代码是最好的答案，也可以是分离问题的好东西。但是，如果我有一个非常依赖嵌套事务的框架/应用程序，我会考虑使用AspectJ来允许自我调用。
As you many know when you proxy an object, like when you create a bean with transactional attributes for Spring/EJB or even when you create a partial mock with some frameworks, the proxies object doesn't know that, and internal calls are not redirected, and then not intercepted either...
That's why if you do something like that in Spring:
@Transactionnal
public void doSomething() {
doSomethingInNewTransaction();
doSomethingInNewTransaction();
doSomethingInNewTransaction();
}
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void doSomethingInNewTransaction() {
...
}
When you call doSomething, you expect to have 3 new transactions in addition to the main one, but actually, due to this problem you only get one...
So i wonder how do you do to handle these kind of problems...
I'm actually in a situation where i must handle a complex transactional system, and i don't see any better way than splitting my service into many small services, so that I'm sure to pass through all the proxies...
That bothers me a lot because all the code belongs to the same functional domain and should not be split...
I've found this related question with interesting answers: Spring - @Transactional - What happens in background?
Rob H says that we can inject the spring proxy inside the service, and call proxy.doSomethingInNewTransaction(); instead. It's quite easy to do and it works, but i don't really like it...
Yunfeng Hou says this:
So I write my own version of CglibSubclassingInstantiationStrategy and proxy creator so that it will use CGLIB to generate a real subclass which delegates call to its super rather than another instance, which Spring is doing now. So I can freely annotate on any methods(as long as it is not private), and from wherever I call these methods, they will be taken care of. Well, I still have price to pay: 1. I must list all annotations that I want to enable the new CGLIB sub class creation. 2. I can not annotate on a final method since I am now generating subclass, so a final method can not be intercepted.
What does he mean by "which spring is doing now"? Does this mean internal transactional calls are now intercepted?
What do you think is better?
Do you split your classes when you need some transactional granularity? Or do you use some workaround like above? (please share it)
I'll talk about Spring and @Transactional but the advise applies for many other frameworks also.
This is an inherent problem with proxy based aspects. It is discussed in the spring documentation here:
There are a number of possible solutions.
Refactor your classes to avoid the self-invocation calls that bypass the proxy.
The Spring documentation describes this as "The best approach (the term best is used loosely here)".
Advantages of this approach are its simplicity and that there are no ties to any framework. However, it may not be appropriate for a very transactional heavy code base as you'd end up with many trivially small classes.
Internally in the class get a reference to the proxy.
This can be done by injecting the proxy or with hard coded " AopContext.currentProxy()" call (see Spring docs above.).
This method allows you to avoid splitting the classes but in many ways negates the advantages of using the transactional annotation. My personal opinion is that this is one of those things that is a little ugly but the ugliness is self contained and might be the pragmatic approach if lots of transactions are used.
Switch to using AspectJ
As AspectJ does not use proxies then self-invocation is not a problem
This is a very clean method though - it is at the expense of introducing another framework. I've worked on a large project where AspectJ was introduced for this very reason.
Don't use @Transactional at all
Refactor your code to use manual transaction demarcation - possibly using the decorator pattern.
An option - but one that requires moderate refactoring, introducing additional framework ties and increased complexity - so probably not a preferred option
My Advice
Usually splitting up the code is the best answer and can also be good thing for seperation of concerns also. However, if I had a framework/application that heavily relied on nested transactions I would consider using AspectJ to allow self-invocation.
这篇关于如何处理Spring / EJB / Mockito代理的内部调用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
