This 2 callback methods seem to be performing almost the same task. From what I can see in BMP, the only difference is ejbRemove contains the necessary sqls to perform the deletion whilst resetting any instance variables to its default / null values. Why then do we need the ejbPassivate method?
ebjRemove and ebjPassivate are very different. ebjPassivate is called by the container only (not by a client), and it temporarily stores a beans state until the container re-activates the bean later by calling ejbActivate.
both ejbPassivate and ejbRemove will be called by container. But the intention of the call is different. In entity bean, ejbPassivate will put the bean back to the pool. In stateful session bean, ejbPassivate will put the bean to secondary storage. In stateless session bean, ejbPassivate will not be allowed.
In entity bean, ejbRemove will also remove the bean from data source and put the instance back to instance pool. In stateful session bean, ejbRemove will remove the bean instance and client can no longer call the methods of this bean, and in stateless session bean, ejbRemove will remove the bean but put it back to instace pool and client does not know that this bean is removed and if they call another method of the bean, a different instance will be picked from the pool to service the client.
As Ray writes, ejbPassivate() and ejbRemove() are only called by the container (as all ejbXXX() methods BTW, which are *all* callback methods).
But there are a few mistakes in all posts above.
- stateful session bean: called by the container when the bean is about to be passivated (state of the bean saved somewhere) after some timeout between a client's calls. - stateless session bean: never called. - entity bean: called by the container when the bean looses its identity (EJBObject and primary key references) before going back to the pool.
- stateful session bean: called by the container when the bean is about to die, as a result of a remove() call done by the client. - stateless session bean: called by the container when the bean is about to die because *the container decided so* (there is *no* link between a client's call to remove() and the ejbRemove() method). - entity bean: called by the container when the *entity* (record in the table) is about to *deleted*, as a result of a remove() call done by the client. The bean *instance* survives, looses its identity (EJBObject and primary key references) and goes back to the pool.
Phil. [ June 21, 2004: Message edited by: Philippe Maquet ]
Do not set lab on fire. Or this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop