• 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
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Transaction Management

 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello

Can we have declarative transaction management at method level for EJB's private methods too. If yes then can we do this for any specific scenario?? Usually we declare transactions for public methods exposed through remote interface. Can someone throw more light on transaction management for private methods??

S V Rao
 
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Declarative transaction demarcation only exists at the public local/remote method level. In fact, if you have a single bean instance with two public methods and one calls the other directly -- this.methodB() -- no transaction demarcation (nor security checks) will be applied. You must go through the component (local or remote) interface to get this as it's the bean's proxy that does the work before calling the bean instance.

This can be tricky, so I'll say it again. Say you have the following bean:By the way, I used this pattern in my session EJBs so that the client didn't have to handle SQLExceptions and figure out which constraint was violated or other reason it failed.

Now, if you call updateUser(), it checks that you are not in a transaction. When updateUser() calls updateUserTransactiona(), if it does so directly (not through the local/remote interface), no transaction demarcation will happen at all. Instead, you must acquire the local interface via the entity context and call updateUserTransactional() through it.
[ December 25, 2004: Message edited by: David Harkness ]
 
s rao
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks David for explaining the concept in such a beautiful manner. The doubt aroused in my mind as the ejb specs doesnt talk anything about transaction handling in ejb private methods. If you can let me know the page number where its clearly mentioned that declarative transaction mentioned can be made only for public methods which are remotely exposed it will be great. Otherwise its very clear to me now from your reply. Thanks once again.
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First, a clarification. Transaction demarcation and security constraints can be applied to any method exposed via either the local or remote component interfaces -- not just remote methods. That this is the case follows directly from the facts that it is the EJBObject proxy to the bean instance that does this work and that it implements the component interface (no private methods).
 
reply
    Bookmark Topic Watch Topic
  • New Topic