Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Remove() method call on Entity bean

 
yogesh shekhawat
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am confused why D is not correct, the data in DB actually removed.
 
Joseph Zhou
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Phil. It about state and action. answer C is talking about action, it is not correct.
 
yogesh shekhawat
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic