aspose file tools*
The moose likes Spring and the fly likes Calling a Bean's Method with Different Transaction Attributes? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Spring
Bookmark "Calling a Bean Watch "Calling a Bean New topic
Author

Calling a Bean's Method with Different Transaction Attributes?

James Dekker
Ranch Hand

Joined: Dec 09, 2006
Posts: 215
What happens if a transactional method with certain transaction attributes call a method at the same bean with different transaction attributes?
Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1648
    
    7

Well that would depend what those 'transactional attributes' are. Are we talking about propogation? Have a look

Here:

http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/transaction/annotation/Propagation.html

and here:

http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/transaction.html#tx-propagation

Generally speaking the the outer transaction configuration determines the actual one used.



[How To Ask Questions][Read before you PM me]
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

James Dekker wrote:What happens if a transactional method with certain transaction attributes call a method at the same bean with different transaction attributes?


Actually, what you have here is a "code smell" basically there is something wrong with the design. So If I have one bean with two public methods a() and b() and both are Transactional. a() calls b(). That call to b will not go through the proxy, you are already in that bean instance. So it will not go out and recall it through the proxy, it calls it directly. So b() in a sense will be in the context of a()s transaction, because it is still in a sense in a().

once you are within the actual instance of the bean it will call other methods in that same instance directly.

So why is that a code smell. 2 possible reasons . 1) a() should not be a client to b(). Basically you are breaking interfaces and their purpose. a public interface is for clients outside of the class. or 2) b() should NOT BE in the public interface. a() is the only "client" of b() and therefore b() should have been declared private.

So the fix, move b() into another interface/another class so that a() can be a public client of b(), or make b() private.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Bill Gorder
Bartender

Joined: Mar 07, 2010
Posts: 1648
    
    7

at the same bean


I missed that

I agree with Marks analysis I thought we were talking about nested transactions across services or layers.

Mark,

The bit about not going through the proxy is specific to interface based proxying correct? I can't recall ever having tried it but I would think using CGLIB and AspectJ class based proxies would allow you to have a nested @Transactional private method in the same bean. I know the aspect j marker would be there and I just always assumed it would work. I know I have had private Transactional methods within services before on a few occasions but that is usually to keep the transaction open for the smallest amount of time needed on service calls which can take some time to complete , and in that case the service method exposed by the interface is not transactional.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Calling a Bean's Method with Different Transaction Attributes?