Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

HFEJB questions 18 on page 371

 
rick collette
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
  • 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,
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • 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
  • 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
  • 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 ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic