• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Liutauras Vilda
  • Paul Clapham
Sheriffs:
  • paul wheaton
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Piet Souris
Bartenders:
  • Mike London

Calling a Bean's Method with Different Transaction Attributes?

 
Ranch Hand
Posts: 229
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What happens if a transactional method with certain transaction attributes call a method at the same bean with different transaction attributes?
 
Bartender
Posts: 1682
7
Android Mac OS X IntelliJ IDE Spring Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.


 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Bill Gorder
Bartender
Posts: 1682
7
Android Mac OS X IntelliJ IDE Spring Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic