This week's book giveaway is in the Programmer Certification forum.
We're giving away four copies of OCP Oracle Certified Professional Java SE 21 Developer Study Guide: Exam 1Z0-830 and have Jeanne Boyarsky & Scott Selikoff on-line!
See this thread for details.
  • 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
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

Transaction attributes and unspecified transaction context

 
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi folks,
I am a bit confused about the different transaction attributes
and the "unspecified transaction context".
Supports, NotSpported and Never can cause an "unspecified transaction context".
What is the general rule of thumb for EntityBeans.
Good design claims that you will have a SessionBean shielding the EntityBeans.
(Therefore the EntityBeans can have a local interface).
So if my SessionBean Method runs as "Required" an Tx will be started and if
this SessionBean then calls an EntityBean that runs also in "Required" or
"Supports" it will pick up the Tx from the SessionBean. However, HF-EJB
says that using "Supports" is a bad idea because of the "unspecified transaction context". So why doesn't HF-EJB also state that "NotSupported"
and "Never" is also a bad idea coz it also can cause an "unspecified transaction context".
Further, what do I do if I have a ReadOnly EntityBean and for performance
purposes I don't want any transaction at all. What would be the Tx Attributes for the shielding SessionBean and the EntityBeans?
TIA!
 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That means that has no sense to get transaction context from a method with "NotSupported" or "Never" Attribute because you always receive that exception because there's no transaction context.
but with "Supports" you cant be sure.
If you dont want transaction in a specific method bean, then why dont you use "NotSupported"?.
 
David Follow
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I use "NotSupported" then I will run into an "unspecified transaction context" as well. "NotSupported" is defined as fallows:
If the method is called with an existing transaction context, the caller's transaction is suspended.
Regardless of whether there is an existing transaction, the method will run in an "unspecified transaction context".
Reading the spec. I wonder if I ever would like to use any attribute appart from Required, RequiresNew, or Mandatory.
Obviously the others are dangers, up to the vendor implementation or whatever...
The EJB2.0 Spec say:
For entity beans that use EJB 2.0 container-managed persistence, only the Required, RequiresNew, or Mandatory transaction attributes should be used
for the methods defined in the bean�s component interface and all the direct and indirect superinterfaces of the component interface, excluding[....]
Containers may optionally support the use of the NotSupported, Supports, and Never transaction attributes for the
methods of entity beans with container-managed persistence. However, entity beans with container-managed persistence
that use these transaction attributes will not be portable.
The Application Assembler should avoid use of the NotSupported, Supports, and Never transaction attributes for
the methods of entity beans with container-managed persistence because it may lead to inconsistent results or
to the inconsistent and/or to the partial updating of persistent state and relationships in the event of concurrent use.
 
Here. Have a potato. I grew it in my armpit. And from my other armpit, this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic