remove() on passivated Statefull session bean...

[amol deshpande]

HI,
If the Statefull session bean is in passivated state and then client calls remove()....i guess the bean will be activated first and ejbRemove() will be called.....am I right...??
Just to confirm!!!
Amol

[Leena Diwan]

No. Not really. From the HFEJB - "Container will not bring a bean out of passivation just to kill it"
Refer page 213 of HFEJB for further details.

Regards,
Leena

[amol deshpande]

Hi Leena,
Thanks for reply.
Thats the only situation the HFEJB dosnt cover in explaination for statefull beans killings.
When bean is passivated and it time outs, thats the case when ejbRemove() is not called ...this is specifically mentioned on HFEJB.
What i thought is that the statement 'Container will not bring a bean out of passivation just to kill it' was may be refering to that scenario..........(may be container would like to be fair with bean and reduce chances when ejbRemove() is not called...just to let it clear stuff its holding in bean...)
But Im not too sure about actual answer......so if you have gone through specification can u refer me to a page in it?(i've not yet touced ejb spec.).

Thanks.
Amol.

[Leena Diwan]

Well, I read the referred page and felt it was more than a conversation!

I have not read the spec too but Im certainly at a stage where I will begin it soon. So I did check the spec for this. I did not find anything of this sort mentioned in the spec.

It might also be dependent on the way the container is implemented. I dunno. May be someone can help us here.

Regards,
Leena

[Gustavo Dutra]

Dear Friends,

page 82 of the specification....

" The Bean Provider cannot assume that the Container will always invoke the ejbRemove() method on a session bean instance. The following scenarios result in ejbRemove() not being called on an instance:
- A crash of the EJB Container.
- A system exception thrown from the instance�s method to the Container.
- A timeout of client inactivity while the instance is in the passive state. The timeout is specified by the Deployer in an EJB Container implementation specific way. "

The specification do not mention anything about the passivate state...
I agree that you spend resources... but.... if you have some logic or verification or desalocation of resources???
The ejbPassivate callback method have to close connections, do things for
the session bean that will be stored.... not removed....

This is my opinion....

Read the page and take your conclusion..

Bye,
Gustavo

[amol deshpande]

Hi,

HFEBJ says that on stateful session,
ejbRemove may be missed if
1) server crash
2)bean timeouts in passive state
3)system exception comes


so now I expect that bean may be in passivated state when remove comes.....that probablity is good one.
And if container doesnt get it in activated state and kills bean directly,
the above list would include the fourth element...which would make spec
incomplete ......
Heance I guess it MAY be shifting it to activated state...unless spec says that its gonna be container managed..........(how I want it should not be!!!)
Amol

[Dan Drillich]

As Gustavo showed us:

A timeout of client inactivity while the instance is in the passive state. The timeout is specified by the Deployer in an EJB Container implementation specific way.

So, no doubt - from the passive state there is no way to invoke the ejbRemove method. It is also being shown in the 'Stateful Session Bean State Diagram' on page #84.

Further down on page #89 on 2.1 spec:

If the session bean instance allocates resources in the ejbCreate<METHOD> method and/or in the business methods, and normally releases the resources in the ejbRemove method, these resources will not be automatically released in the above scenarios. The application using the session bean should provide some clean up mechanism to periodically clean up the unreleased resources.

Not exactly exciting to know that we can't rely on the fact the ejbRemove is being called every time. At least the specification is very clear about it.

Regards,
Dan