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.
Win a copy of OCP Oracle Certified Professional Java SE 11 Developer Practice Tests this week in the OCP forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Ron McLeod
  • Tim Cooke
Sheriffs:
  • Devaka Cooray
  • paul wheaton
  • Mark Herschberg
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Frits Walraven
  • Jj Roberts
Bartenders:
  • Carey Brown
  • salvin francis
  • Piet Souris

Remove() method call on Entity bean

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Life just hasn't been the same since the volcano erupted and now the air is full of tiny ads.
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic