Some questions

[Vipin Mohan]

hi friends
Got a couple of questions bothering me.
1. Whats the result of invoking the remove() method on passivated stateful session bean ? Will ejbRemove() be called ?
2. If remove() method is invoked on an entity bean in the pooled state, will ejbActivate() and ejbLoad() be invoked on it, before calling the ejbRemove() method ?
Thanks a lot
Vipin
[ December 20, 2003: Message edited by: Vipin Mohan ]

[Mikalai Zaikin]

hi, Vipin
1. There is nothing in spec about removing from passivated state except as a timeout. Also, cpec clearly says that SFSB will be activated before any method call in passiveated state. So, my guess is:
a) bean will be activated
b) ejbRemove will be called
2. Sure, I think, the bean (will not say which one exactly - all of them are equal) will be :
a) activated - ejbActivate
b) loaded - ejbLoad
c) removed - ejbRemove
then bean will return to the pool.
p.s. I may be wrong

[Vipin Mohan]

I think you are right.
Thanks for the explanations, Mikalai.
Vipin

[Sudeep das]

hi guys,
adding on to your discussions,
I doubt about that the container will bother to actiavate() a bean again if it is already passivated.
If we look from the containers point of view then it's like this...
The bean is passivated... the container is wating for timeout to pass so that it can remove the bean.
Now the client calls ejbRemove(), now as the bean is already passivated, the container can safely assume that as a developer we have taken care of the state of the bean in the respective methods, therefore eventhough there is nothing in the discussion regarding the passivated session bean getting a remove() call, the container will never call its ejbActivate(), ejbLoad() and then call ejbRemove().
To justify my answer just think of yourself....
There is law you have to abide by... which says go to your home after school. It doesnot specify which way you choose to go. Being a guy to follow the rules and knowing that there is no rule on way to follow would you take the longest way to go back to home or the shortest way.
The obvious answer is the shortest way.
To activate() and load() a bean is a heavy task for any container, so the container will never say "ok i will reactivate() and reload() the bean just to delete it again...
sudeep

[Magnus Stattin]

In the case of a cascade delete the entity bean has to be activated and loaded before it is removed. In this case the bean has to get the correct state for the beans that is in a relationship with the bean so they can be deleted as well.
/Magnus

[Vishwa Kumba]

Originally posted by Vipin Mohan:

1. Whats the result of invoking the remove() method on passivated stateful session bean ? Will ejbRemove() be called ?

I also tend to agree with Sudeep, for Stateful session beans.
I think most of the times, the code that goes into ejbPassivate() also goes into ejbRemove(), so this piece of code might not get executed when the bean times out in a passivated state, b'cos the code would already been executed once in the ejbPassivate() method just before passivation.
HF EJB book-p:211, Lifecycle overview - SFSB - "Bean times out while passivated" - also says that the container does not call ejbRemove() method when it decides to remove the bean.

[Vipin Mohan]

hi folks
Now I'm really confused. That argument sounds reasonable too.
Can Kathy or Bert please give us the answer to this ?
Thanks
Vipin

[Kathy Sierra]

Howdy -- for stateFUL session beans, the container will treat a remove() method as a business method, and "wake up" the bean to invoke the ejbRemove() method (so ejbActivate() will be called first).
When a bean times out while passivated, the container does NOT "wake up" the bean, because it knows that the relationship between this bean and this client is already OVER, as far as the container is concerned, so there is nothing else to be done.
But the container treats a remove() call as something active from the client -- something that means the client/bean relationship is still alive and well, even if the remove() means "Hey bean, I'm done with you now... so complete my conversation with you... finish my session." and the bean may do something *related to that client*.
So the big question is about WHERE do you do your cleanup, and you still must assume that ejbRemove() might not be called (because of all the other issues -- server crash, timeout while passivated, system exception) so, here would be my advice:
* Do NOT rely on ejbRemove() for your clean up.
* Do NOT assume ejbRemove() will be called.
* Use ejbRemove() for extra client-session-specific things that you want to do as a result of KNOWING that the client has actively said he is done talking to you. But do not put crucial clean-up code in here.
So, when is ejbRemove() called on a session bean?
1) When the container *chooses* to remove a stateLESS bean.
2) When the client calls remove() on a stateFUL bean, and the bean is either passivated or active.
When is ejbRemove() NOT called?
1) When the bean (any type) throws a system exception.
2) When the container crashes
3) When a stateFUL bean times out while passivated.
Now, just one little clarification... a few of you have mentioned ejbLoad(), but remember... there is NO ejbLoad() for session beans
Only entity beans are activated and loaded. StateFUL beans are simply activated, and then the business method (or in this case, the ejbRemove()) is called.
cheers,
Kathy
"One test to rule them all. One test assigned them. One test to bring them all and in Prometric grind them."

[Rashmi Tambe]

Originally posted by Kathy Sierra:
When is ejbRemove() NOT called?
1) When the bean (any type) throws a system exception.
2) When the container crashes
3) When a stateFUL bean times out while passivated.

Suppose the ejbRemove() method in the SF session bean contains some cleanup code, which is assumed to be executed , when the bean is removed (or destroyed ). So what happens in case of pt# 3? in the passivated state, if the bean is removed due to time out and ejbRemove() is not called by the container, when does the cleaup excute? rather where shd this cleanup code be written to make sure that it is always executed when the bean is removed?

Is ejbRemove() still a safe place to do cleanup, if the container does not guarantee that ejbRemovbe() is always executed??? (referring to pt#3)

[Vishwa Kumba]

Originally posted by Rashmi Tambe:
Is ejbRemove() still a safe place to do cleanup, if the container does not guarantee that ejbRemovee() is always executed??? (referring to pt#3)

Rashmi,
In the above Kathy's post, it is mentioned that ejbRemove() is not always a reliable method...
Read the foll. post also....HTH!
https://coderanch.com/t/158460/java-EJB-SCBCD/certification/where-put-critical-cleanup-things