Multiple New Txns From Inside Txn Wrapped Method?

[sethladd]

Hello,

We have a Service facade that presents our transactional boundaries. We have one method that updates many different objects. If one object fails its update, we'd like to move on and continue. Each update is a distinct transaction.

Something like:

public void doAll() {
iterate {
this.doForOne(); // this is one distinct transaction
}
}

This service facade is wrapper in a txn AOP proxy.

It's my understanding that when a proxied object is calling itself (as we do here with doForOne()), those calls do not go through the proxy.

How would I, in this case, tell doForOne to be REQUIRES_NEW via the txn proxy wrapper AND have doAll respect that?

I don't want to have another process perform many roundtrips for these operations. I'd love it if I could have them all done with one call to my service facade.

Any tips? Thanks very much!
Seth

[Colin Sampaleanu]

You can get at your own proxy within a proxied object, by using
AopContext.currentProxy()
obviously, this means your code is now Spring aware. The best thing to do would probably be to wrap this in some utility code. If you do want to use this approach, note that you need to set the exposeProxy property on your proxy factory to true, as it's false by default.

[sethladd]

Thanks Colin,

I'm not sure I quite understand your suggestion. I think you're saying, if I get the proxy from within my object, I can route calls through the proxy instead of "this".

Am I correct in understanding that a Proxied Bean, when calling methods internally, won't go through the Proxy? This seems like something that would be useful, especially for the situation I mentioned.

So, if I understand you, here's what the code would look like:

public class ServiceBean {

  public void doAll() {
    txnproxy = AopContext.currentProxy();
    iterate {
        txnproxy.doSingle(); // in NEW txn
    }
  }

  public void doSingle() {
    // should happen in its own TXN regardless
  }

}

NOTE To get the above to work, you will have to set 'exposeProxy' property on Advised first. This turns on proxy tracking. I'll figure out how exactly to do with with BeanNameAutoProxyBean.

Thanks!
seth

[Colin Sampaleanu]

Yes. That presumes that the method is marked REQUIRES_NEW of course.

[sethladd]

Thanks Colin!

Am I correct in assuming that the AspectJ integration will solve issues like this? Using AspectJ, I won't need the proxy anymore.

That will be great!
Seth

[Rod Johnson]

I recently refactored the TransactionInterceptor to pull out a base class that could also be used by an AspectJ transaction aspect using all of Spring's transaction capabilities. Unfortunately I haven't had time to progress the AspectJ side of it beyond what's in the samples module. I hope to complete this for 1.2.

[sethladd]

That sounds great, thanks Rod! We're really looking forward to this kind of integration. We usually are very happy the Proxy based AOP, but looks as if the AspectJ AOP is the only way to handle some types of situations.

[sethladd]

I'm finally getting around to refactoring our code to take advantage of the AopContext.currentProxy() code.

All of my code is advised via the BeanNameAutoProxyCreator.

Does anyone recommend a way to set exposeProxy attribute when using the BeanNameAutoProxyCreator?

Thanks very much!

[sethladd]

Well, Turns out that even though BeanNameAutoProxyCreator doesn't implement Advised, it does subclass ProxyConfig, which has a similar property exposeProxy.

So I will attemp to set that and see how it goes.

[CameronBraid]

One way to make proxies non spring dependant - i.e. not using the AopContext.currentProxy() method - is to provide a setter on the proxied class that gets called by the proxy creator.

class MyService {
  MyService proxy;
  public void setProxy(MyService proxy) {
    this.proxy = proxy;
  }

  public void nonTrans() {
    proxy.doTransA();
    proxy.doTransB();
 }

 @Transactional
 public void doTransA() {
    ...
 }


 @Transactional
 public void doTransB() {
    ...
 }

}