dbt on Missed ejbRemove()

[Suchitra Bhat]

Hi All,

I am little confused whether ejbRemove() will be missed in the following case.

Client calls remove() when stateful session bean is in passivation.
Does the bean directly go to "does not exist " state or it will be brought back to the active state and then ejbRemove() is called ?

Thanks,
Suchitra

[Pavel Kubal]

Bean will be activated and callback ejbRemove will be called.

[cheenu Dev]

Bean will be activated and callback ejbRemove will be called.

where did you read this?
from figure there is nothing as of the way you suggest.

Does the bean directly go to "does not exist " state

yes bean directly goes to does not exist state.

brought back to the active state

whats the need to bring it back to active state.
anyway it is going to be killed.

[Suchitra Bhat]

Yes, there is no need to bring back the bean to active state when it is going to be killed.
But in HFEJB it is clearly mentioned that

Exam expects you to know that there are 3 circumstances under which a bean will not ger an ejbRemove() call
1 Server crashes
2 Bean times out while passivated
3 Bean throws system exception

But it is not mentioned what happens when client calls remove() while bean is in passivation.
So i am still confused.
Can some one please clarify ?

[Ramasubbhu Allur Kuppusamy]

Originally posted by Suchitra Bhat :

Client calls remove() when stateful session bean is in passivation.
Does the bean directly go to "does not exist " state or it will be brought back to the active state and then ejbRemove() is called ?

The bean goes directly to the "Does Not Exist" State.

[Pavel Kubal]

Spec says, that object's invocation brings bean from passive state to active state. Than method remove will be called and ejbRemove callback will be called by container. That's from spec.

Where did you get your ideas?

[Ugender Rekulampally]

I think Pavel is right on this one. I think that ejbRemove also any other method, and container activates the bean instance and calls remove on the bean instance.

Yes, it does n't make much sense to activate and remove but how the container knows about the method? it all does is, invocate the bean first for every method call from the client.

Please feel free to add any comments.

Thanks,
Ugender

[cheenu Dev]

When the client calls remove on the home or component interface to remove the session object, the container issues ejbRemove() on the bean instance.

from pg 79 of spec.
Suchitra Bhat thanks for this great question.
so you will have container callback ejbRemove() for sure.
Pavel Kubal is right!

[Vivek Kinra]

When the client calls remove on the home or component interface to remove the session object, the container issues ejbRemove() on the bean instance.

I think still there is a confusion on this question because what Cheenu mentioned from specs...is the case when the session instance is in ready state and it is no where mentioned on specs, what will happen when a remove call is made while the instance is in the passivated state...

Thanks

[cheenu Dev]

is the case when the session instance is in ready state

where it is mentioned in specs it is for ready state?
in specs it starts as,

The following steps describe the life cycle of a STATEFUL session bean instance:

in page no:78

[Charlie A]

Pavel is correct. The ejbRemove method will be called if the remove method is called by client when a bean is passivated state.

Couple of things you need to consider:

1) When a bean is in passivated state, it has only two exits from that state - timeout or activation. The bean will move to "Does not exist" state only when it is timed out.

2) Considering the bean in passivated state, and the client invoking a method on the bean will bring back to the "Method Ready" state; i.e. ejbActivate() method is called.

3) The client will not be aware whether the bean is passivated or activated state, since it totally depends upon the container.

From the 1st point you can tell that the bean will not directly go to the "does not exist" state, since there is no time out.
So the only exit remaining for the bean is to come back to the active state. So when the client calls the remove() methods , the methods will invoked in the following sequence
remove() --> ebjActivate()-->ejbRemove

[Vivek Kinra]

Thanks Charlie....

[ramesh jaga]

when the client calls remove on a bean that has been in passivated state,the container first invokes ejbActivate to bring back the bean to method ready state then the ejb remove is called on the bean to remove the bean.