• 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
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

unSetEntityContext()

 
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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)
 
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanQ Kathy thanQ very much for ur quick reply
 
There is no greater crime than stealing somebody's best friend. I miss you tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic