This week's book giveaway is in the OCP forum. We're giving away four copies of OCP Oracle Certified Professional Java SE 11 Developer Practice Tests and have Scott Selikoff and Jeanne Boyarsky on-line! See this thread for details.
Here is one question from SCEA Exam simulator of whizlab which I think is confusing
what happens when the remove() method is called on the Home interface of an entity bean ?
A. The remote interface is invalidated B. The bean instance is destroyed c. The bean instance is passivated d. The data represented by the bean instance is deleted from the database. E. The bean instance moves from pooled state to ready state.
I think correct answer should be A,C and d but as per whizlab simulator I am using A and d are only correct answers. Reason they have given why c is incorrect because container passivate the bean instance whenever required(for memory management). It is not a consequence of the remove() method though.
which is true in most cases but in this case after calling remove() method when remote interface/stub is invalidated and bean instance goes back to pooled state and it is already passivated . I don't see any reason why passivation is going to be container dependent here. So I think c should be also correct in this case.
I would appreciate further comment to clarify this. [ August 24, 2008: Message edited by: yogesh shekhawat ]
Hi Yogesh, The explanation is in the entity bean lifecycle (see EJB specs p168): A bean passes from the method-ready state to the pooled state either through ejbPassivate() *or* ejbRemove(). So when remove() is called (either on the component interface or the home interface), ejbPassivate() will not been called. Hence answer 'c. the bean instance is passivated" is incorrect. Regards, Phil.
Hi Phil, You are right that ejbPassivate is not called in this case but ejbRemove does get called which removes data from database and invalidate remote interface/stub . Any future reference to this bean instance seems to throw exception NoSuchObjectException ,Which makes me belive that after calling ejbRemove() on bean instance it seems to go back in pooled state which can be only possible when bean is already passivated. So I think option C. "The bean instance is passivated" also seems like correct option in this case. Regards, Yogesh
It does, but through ejbRemove(). For entity beans, the pooled state uis not a "passivated" state. So option C "The bean instance is passivated" refers to ejbPassivate(). Answer C is not precise enough, but that's how I understand it. Regards, Phil.
Hi Yogesh, I guess that you refer to this excerpt of the specs:
public void ejbRemove() (...) Since the instance will be entered into the pool, the state of the instance at the end of this method must be equivalent to the state of a passivated instance. This means that the instance must release any resource that it would normally release in the ejbPassivate() method.
Based on ejb specs 1.1 (pg 106),it seems clear that bean instance is already in pooled state(equivalent to passivated) after romove() method call and it is not container dependent for passivation.
I think that when you write "in pooled state(equivalent to passivated)", you mix actions and states: passivating an instance (ejbPassivate()) is an *action* which eventually leads the bean back in the pooled state. As removing (ejbRemove()) is another action which eventually leads the bean back in the pooled state. If you agree with that, answer C. "The bean instance is passivated" becomes obviously incorrect. The bean goes back in pooled state (OK), but not through passivation. Regards, Phil.
passivated is state like pooled state of bean instance and passivation is process or action. So as per my understanding option C seems to be talking about state not "Action". It is like asking "The bean instance is pooled(passivated)" [ August 24, 2008: Message edited by: yogesh shekhawat ]
Here is what I was referring in ejb specs 1.1 at page 106
� public void ejbRemove(); [.........] An entity bean instance should use this method to remove the entity object�s representation in the database. Since the instance will be entered into the pool, the state of the instance at the end of this method must be equivalent to the state of a passivated instance. This means that the instance must release any resource that it would normally release in the ejbPassivate() method.
It can understood though as "must be equivalent to the pooled state of an instance which was passivated". Language is slightly vague and not very clear here
------------ Yogesh Shekhawat SCEA Part-1
[ August 24, 2008: Message edited by: yogesh shekhawat ] [ August 24, 2008: Message edited by: yogesh shekhawat ]
the state of the instance at the end of this method must be equivalent to the state of a passivated instance.
Yanqu is correct. "must be equivalent to the state of a passivated instance" must be understood as "must be equivalent to the state (pooled) of an instance which was passivated". That excerpt of the specs would be vague only in the case some "passivated" state would exist in the entity bean lifecycle. But as it's not the case, there is only one possible interpretation of it. Regards, Phil.
Life just hasn't been the same since the volcano erupted and now the air is full of tiny ads.