Spring @Transactional method - participating transaction?

When using Transactional, you're dealing with proxies of classes, so in this scenario.

Proxies in Spring AOP When using Transactional, you're dealing with proxies of classes, so in this scenario: @Transactional public void doSomeThing(){ // calling this method targets a proxy doSomeThingElse(); // this method targets the actual class, not the PROXY, // so the transactional annotation has no effect } @Transactional public void doSomeThingElse(){ } you are calling the proxy from outside, but the second method call is made from inside the proxied object and therefor has no transactional support. So naturally, they run in the same transaction, no matter what the values of the @Transactional annotation in the second method are so if you need separate transactions, you have to call yourservice.doSomething(); yourservice.doSomethingElse(); from outside. The whole scenario is explained pretty well in the chapter Spring AOP > Understanding AOP proxies, including this "solution": Accessing the Current AOP Proxy object from the inside public class SimplePojo implements Pojo { public void foo() { // this works, but... gah!((Pojo) AopContext.currentProxy()).bar(); } public void bar() { // some logic... } }.

The default value of the propagation attribute of @Transactional is REQUIRED, which means: Support a current transaction, create a new one if none exists. So yes - both methods will run in the same transaction. But one important advice: don't make your DAO transactional.

The services should be transactional, not the DAO.

In my case dao and service is the same thing. I only need 1 method that runs 2 dao methods. So instead of creating a separate Service class I think my solution is simpler.

If you have counter-arguments, please advise me why my approach is worse. I don't see any means in creating a new class just for 1 method. And wrap all invocations to dao into service layer, then what?

Double-coding? – EugeneP May 19 '10 at 12:09 1 @EugeneP: the rationale for wrapping things in services is that as your app grows you will be able to accommodate the complexity using a layered architecture with well-defined responsibilities. Already it sounds like your DAOs are becoming more complex than they should be.

– Nathan Hughes May 19 '10 at 16:01.

Spring doc one note: In proxy mode (which is the default), only external method calls coming in through the proxy are intercepted. This means that self-invocation, in effect, a method within the target object calling another method of the target object, will not lead to an actual transaction at runtime even if the invoked method is marked with @Transactional.

Ok, I see most people don't know it, see other replies. So what if I use propagation Required explicitly or something like that? Would that help?

– EugeneP May 19 '10 at 12:11 it must help! Or this external calls thing would prevent? – EugeneP May 19 '10 at 12:28 @EugeneP, only external methods calling are intercepted, regardless propagation attribute of @Transactional.

But you may try to use aspectj weaving and take full controll on transaction process PS:I didn't try this (aspecj weaving transaction) so I can't help with this – Yuri. Bulkin May 19 '10 at 12:54.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.