Remove() method call on Entity bean

[yogesh shekhawat]

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 ]

[Philippe Maquet]

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.

[yogesh shekhawat]

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

[Philippe Maquet]

Hi Yogesh,

it seems to go back in pooled state

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.

[Philippe Maquet]

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.

[Joseph Zhou]

I am confused why D is not correct, the data in DB actually removed.

[Joseph Zhou]

I agree with Phil. It about state and action. answer C is talking about action, it is not correct.

[yogesh shekhawat]

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 ]

[Joseph Zhou]

Most time you are right except in a exam. I search the spec.1.1 page 106 using "passivate", I did not find any "passivated" as an alternative of "pooled", so IN EXAM, c is not correct.

[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 ]

[Philippe Maquet]

Hi Yogesh,

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.