• 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • salvin francis
  • fred rosenberger

when is a transaction started with entity beans?

Ranch Hand
Posts: 277
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
Page 348 of HF says that after a business method is called on the ejbObject

The Container sees that this method needs a transaction, so the container starts one, then pulls a bean from the pool, and calls ejbActivate() on the bean.

So one would assume that since the container started a transaction before calling ejbActivate() on a bean that the bean would be in a 'meaningful transaction context'.
This assumption is contradicted by the note on the bottom of page 354 which says

The container prefers(no, make that INSISTS) that if you access a bean or a resource manager, you must be in a 'meaningful transaction context', so ejbActivate() is too early.

Why is this the case, since according to the first quote, the container begins a transaction prior to calling ejbActivate().
Thanks in advance.
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Keith,
I assume the scenarion is something like : the bean instance has been passivated and the container receives a call due to which it decides to activate the instance.
In the passivated state, the instance has no object identity, the identity is assigned only after the bean has been activated i.e return of ejbActivate. So the container / Tx manager would enlist the instance in the transaction only when the object identity has been re-created for the instance and this happens only after the ejbActivate . So I guess that is the reason ejbActivate will be called in an unspecified transaction context.
I am not sure about this, just my guess.
Also, activation /passivation is upto the discretion of the conatiner. The bean cannot be passivated during an ongoing transaction. So ths implies that when a bean is passivated, there is no Tx asscoaited with the "passivation" . And hence the activation may also not be associated with a Tx since passivation and activation go hand in hand ..
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I do not know the answer to Keith's question, but can comment on Akasmat's view...
I think SFSB cannot be passivated when they are in a transaction, but entity beans can be passivated by the container if they are in a transaction.
If the entity/session bean client calls a business method for a bean in a passivated state, another bean from the pool will be picked up by the container to service the client.
Attractive, successful people love this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
    Bookmark Topic Watch Topic
  • New Topic