where to put critical cleanup things for stateful session bean?

[Yi Meng]

It seems that we cannot rely on ejbRemove() and ejbPassivate().
So where to put theose critical cleanup things?
Is it that the only way is to acquire and release those critical things (resources) within each and every method when in need?
Even in this way, the resource may not be released if say in the method resources have been acquired but before they could have been released a system exception occurs and the bean dies.
So in essential, there is NOT a way that critical cleanup things could be done 100% for sure.
correct me if i miss somewhere.....

[Vishwa Kumba]

Originally posted by Yi Meng:
It seems that we cannot rely on ejbRemove() and ejbPassivate().
So where to put theose critical cleanup things?

As mentioned by Kathy, in the other post...the ejbRemove() method may not be called in the foll 3. scenarios :
1. EJB Server Crash
2. SFSB timesout in a passivated state
3. An runtime-exception occurs
So in real projects, We may be required to write tools that perform a periodical cleanup of the resources, held up by the dangling stateful session beans. My guess is that Stateful session beans are not really as popular as Stateless session beans... :roll:

[Kathy Sierra]

It is often best to just have your business methods be as self-cleaning as possible... but of course there are a gazillion reasons why that is not always a good idea. But for example, if your bean uses a database connection, it's probably a good idea to release that connection at the end of each business method that uses it (or even earlier) rather than trying to hold it for the life of the bean (say, by setting it in setSessionContext() and releasing it in ejbRemove(), or by getting and releasing it in ejbActivate() and ejbPassivate(). This way, you'll have it for the least amount of time (good from a scalability standpoint) and you'll have less to worry about if the ejbRemove() call doesn't happen. Yes, there's a teeny bit of overhead in getting and releasing the connection, although because of pooling, it's extremely INexpensive to do it, and usually worth the extra overhead.
cheers,
Kathy

[Yi Meng]

so is it a good practice to save a reference to DataSource(found through jndi) in an attribute so that whenever there is a need to do JDBC stuff in a business method, i use the reference to get a connection and close it when finish?
Is this alright for servlet? (i.e. save a reference to DataSource found through jndi in the init() method and subsequesntly use it to get a connection)

[Kathy Sierra]

Originally posted by Yi Meng:
so is it a good practice to save a reference to DataSource(found through jndi) in an attribute so that whenever there is a need to do JDBC stuff in a business method, i use the reference to get a connection and close it when finish?)

Yes! It is the DataSource lookup in JNDI that is expensive, *not* the getting/releasing the connection from the pool. So in general, that would be a good practice.
cheers,
Kathy