Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

unSetEntityContext()  RSS feed

 
eswar kumar
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi everybody im new to EJB , when the EJB instance moves from pooled state to Doesnot exist state .( not by calling unSetEntityContet() this is called by container .. im asking by which method calling by the client bean instance moves to doesnot exist state)
 
Kathy Sierra
Cowgirl and Author
Rancher
Posts: 1589
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy -- the client cannot cause an entity bean *instance* to move to the does not exist state... only the Container can make that decision, and calls unsetEntityContext() (unless the bean throws a system exception). The client calls remove() to ask for the *entity* in the underlying store to be deleted (e.g. the row in the database), but the bean instance that had been acting as that entity just slides back into the pool.
The only time an entity transitions to does not exist is if the Container decides there are too many beans in the pool (which may or may not be a tweakable feature of your particular server).
So... here's the deal about remove():
StateFUL session bean -- client calls remove(), Container calls ejbRemove() on the bean (unless the bean is already passivated), and the bean moves to does not exist.
StateLESS session bean -- client calls remove(), Container says, "OK, nice to know that YOU are done, but somebody else can use this perfectly good bean.." and the Container does NOT call ejbRemove() on the bean. But at some other point (not initiated by the client), the Container *can* call ejbRemove() to kill the bean, but only because the Container thinks the pool is too big.
Entity bean -- client calls remove(), Container calls ejbRemove() on the bean and (for CMP beans, and assuming you don't throw a RemoveException) the underlying entity in the persistent store is deleted, and the bean slides back to the pool. If the Container later wants to reduce the pool size, it can call unsetEntityContext() to send the bean to does not exist.
So, unsetEntityContext() exists ONLY because ejbRemove() has a completely different meaning for Entity beans, so they had to come up with a 'cleanup-you-are-about-to-die' method for entity beans.
cheers,
Kathy
 
eswar kumar
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanQ Kathy thanQ very much for ur quick reply
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!