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
