g*****g
发帖数: 34805 | 1 我有一个spring bean，里面有一个方法。大致就是每发一个email, 然后修改
一些数据库的值。这个方法要对一个List做这样的操作。
我用spring 的TransactionProxyFactoryBean来做这个操作，并没有问题。
所有email先发出去，然后Transaction才commit。
现在设计需要修改一下，希望每发一个email，数据库修改就commit一次。
于是我把这些代码单独拉出来做成一个public的方法notifyRecipientsTx，
并设成PROPAGATION_REQUIRES_NEW，但发现每次调用这个方法的时候并没有
产生一个新的transaction。这是什么引起的呢？是不是因为在同一个类里面，
没有透过spring的proxy来获得bean，所以不行？除了用programmatic transaction，
有什么好的办法？这个spring bean的定义如下
class="org.springframework.t | g*****g
发帖数: 34805 | 2 It seems self-invocation is the problem for AOP, I have to find a way to
refactor the code and basically make this function in another bean so it's
called on a proxy, or I have to use aspectJ, ft.
【在 g*****g 的大作中提到】
: 我有一个spring bean，里面有一个方法。大致就是每发一个email, 然后修改
: 一些数据库的值。这个方法要对一个List做这样的操作。
: 我用spring 的TransactionProxyFactoryBean来做这个操作，并没有问题。
: 所有email先发出去，然后Transaction才commit。
: 现在设计需要修改一下，希望每发一个email，数据库修改就commit一次。
: 于是我把这些代码单独拉出来做成一个public的方法notifyRecipientsTx，
: 并设成PROPAGATION_REQUIRES_NEW，但发现每次调用这个方法的时候并没有
: 产生一个新的transaction。这是什么引起的呢？是不是因为在同一个类里面，
: 没有透过spring的proxy来获得bean，所以不行？除了用programmatic transaction，
: 有什么好的办法？这个spring bean的定义如下
| t*******e
发帖数: 684 | 3 Just call the flush method explicitly, assuming the app has Hibernate/JPA
running underneath. ORM solutions always defer database commit to reduce IO and improve performance. | g*****g
发帖数: 34805 | 4 I am using hibernate, Tried that, didn't work.
IO and improve performance.
【在 t*******e 的大作中提到】
: Just call the flush method explicitly, assuming the app has Hibernate/JPA
: running underneath. ORM solutions always defer database commit to reduce IO and improve performance.
| m******t
发帖数: 2416 | 5
Yes, that's pretty much it. It's a known limitation of spring aop.
【在 g*****g 的大作中提到】
: It seems self-invocation is the problem for AOP, I have to find a way to
: refactor the code and basically make this function in another bean so it's
: called on a proxy, or I have to use aspectJ, ft.
| s******e
发帖数: 493 | 6 As magicfat said, it is spring's limitation.
to understand this, I just want to add my two cents.
Basically, there are three types of AOP
1. like aspectj, the aspect will be woven during compilation time
2. like jboss, the aspect will be woven during class loading time.
3. like spring, the aspect will be woven during run time. And remember that
everything(almost true) in spring is singleton.
Put this together, you can see that there is no easy way for spring to solve
this limitation. | s***e
发帖数: 122 | 7 spring (with aspectj) also have loading time weaving with its spring-agent.jar.
but for lz's specific problem, i think refactoring to avoid self-invocation
is the best way.
that
solve
【在 s******e 的大作中提到】
: As magicfat said, it is spring's limitation.
: to understand this, I just want to add my two cents.
: Basically, there are three types of AOP
: 1. like aspectj, the aspect will be woven during compilation time
: 2. like jboss, the aspect will be woven during class loading time.
: 3. like spring, the aspect will be woven during run time. And remember that
: everything(almost true) in spring is singleton.
: Put this together, you can see that there is no easy way for spring to solve
: this limitation.
| t*******e
发帖数: 684 | 8 Internal method calls bypass AOP proxy in Spring as well as Seam. The
keyword "this" is tough to handle in the proxy object.
There is a workaround, using Spring/Seam API to locate a proxied "this" bean, and invoking the internal method on the proxied "this".
In Spring, BeanFactory.getBean("this bean");
In Seam, Component.getInstance("this bean"); |
|
|
