• 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

HFEJB questions 18 on page 371

 
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am a bit confused about this one:

why do ejbLoad, ejbRemove and ejbSelect run in the transaction context of
the method that causes their onvocation?

Because they can be invoked by clients?

thanks,
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Have you read pages 174-178 in the EJB 2.0 specification?

Why? - because the specification says so.
Why would they specify the required behaviour this way? - I would have to guess the answer.
Why can't you specify a transaction attribute on ejbLoad, ejbStore, and ejbRemove?

Again I'm guessing. I think that a transaction attribute on those methods would be to constraining.

ejbRemove is invoked when remove is invoked via the Component or Home interface - so it makes sense that it would execute in the transaction context as specified by the transaction attributes on those methods.

ejbLoad would get invoked whenever a business method is invoked to ensure that the bean has up-to-date data - all these business methods may have different transaction attributes specified - so the ejbLoad is much more "reusable" if it simply takes the context of the invoking method rather than trying to impose its own.

ejbSelect can be used by different business methods or home business methods - so this case is similar to ejbLoad.

Also note that all three methods access the underlying persistent store.
 
rick collette
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, Peer.

I guess the reason why they run in the transaction context is because they all access persistent store which needs to have data consistency.


Originally posted by Peer Reynders:
Have you read pages 174-178 in the EJB 2.0 specification?

Why? - because the specification says so.
Why would they specify the required behaviour this way? - I would have to guess the answer.
Why can't you specify a transaction attribute on ejbLoad, ejbStore, and ejbRemove?

Again I'm guessing. I think that a transaction attribute on those methods would be to constraining.

ejbRemove is invoked when remove is invoked via the Component or Home interface - so it makes sense that it would execute in the transaction context as specified by the transaction attributes on those methods.

ejbLoad would get invoked whenever a business method is invoked to ensure that the bean has up-to-date data - all these business methods may have different transaction attributes specified - so the ejbLoad is much more "reusable" if it simply takes the context of the invoking method rather than trying to impose its own.

ejbSelect can be used by different business methods or home business methods - so this case is similar to ejbLoad.

Also note that all three methods access the underlying persistent store.

 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by rick collette:
I guess the reason why they run in the transaction context is because they all access persistent store which needs to have data consistency.



You're right in most of the cases. Keep in mind though that there also is the concept of an "unspecified transaction context" (which translates to: "the EJB container can do whatever it wants") - i.e. you don't know if there is a transaction or not. This gives rise to the strange situation where the absence of a transaction can be considered a "transaction context".

For example, if you have a business method that is configured with the "Not Supported" transaction attribute then the lack of a transaction will propagate to the ebjLoad or ejbSelect (or ejbRemove if remove() is the invoked method). Now if the underlying persistent store does support transactions, it will probably just auto-commit in the case of an ejbRemove.
[ October 13, 2005: Message edited by: Peer Reynders ]
 
Space seems cool in the movies, but once you get out there, it is super boring. Now for a fascinating tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic