Originally posted by Marco Tedone:
Given the following question:
HF teaches us that when an entity is removed, the entity bean dies, but the entity bean instance is moved back to the pool. Doesn't this mean that after ejbRemove() the container might invoke ejbPassivate to move the bean instance back to the pool?
Nopes ... According with spec at page 169
Eventually, the container will transition the instance to the pooled state. There are three possible
transitions from the ready to the pooled state: through the ejbPassivate() method,
through the ejbRemove() method, and because of a transaction rollback for ejbCreate(),
ejbPostCreate(), or ejbRemove() (not shown in Figure 23). The container
invokes the ejbPassivate() method when the container wants to disassociate the
instance from the entity object identity without removing the entity object. The container
invokes the ejbRemove() method when the container is removing the entity object (i.e.,
when the client invoked the remove() method on the entity object�s component interface or a
remove() method on the entity bean�s home interface).
So, the bean goes from ready state to pooled state by ejbRemove OR ejbPassivate.
Originally posted by Valentin Crettaz:
First of all, the statement doesn't even mention that the question is about entity beans. The fact that all options are methods in the EntityBean interface doesn't mean anything... Moreover, it is not clear at all what "when invoking ejbRemove()" means. Is it just before or just after the invocation... This question needs serious rework in my opinion.
I agree with you
Originally posted by Valentin Crettaz:
Well, let's assume we are talking about entity beans and that the question asks which methods can be invoked after ejbRemove(). If you have a quick look at my bean lifecycle cheatsheet (page 1), you'll see that after ejbRemove() the container can invoke ejbFind<METHOD>(), ejbSelect<METHOD>(), ejbActivate(), ejbPostCreate<METHOD>(), ejbHome<METHOD>() and unsetEntityContext(). From the available options, only D is correct. A is wrong since the method name does not include some arbitrary suffix (aka <METHOD> .
I disagree ... According with spec ta page 172
The container invokes the ejbRemove() method on an entity bean instance in response to a
client-invoked remove operation on the entity bean�s home or component interface or as the
result of a cascade-delete operation. The instance is in the ready state when ejbRemove() is
invoked and it will be entered into the pool when the method completes.
If the cascaded-delete bean were not activated, the container would called ejbActivate then ejbLoad because the bean must be in the ready state to be removed.
ejbStore wasn�t necessary because the bean�s state wasn�t changed.
Regards
[ August 09, 2004: Message edited by: Vinicius Boson ]