• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

where to put critical cleanup things for stateful session bean?

 
Yi Meng
Ranch Hand
Posts: 270
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Cowgirl and Author
Rancher
Posts: 1589
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 270
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Cowgirl and Author
Rancher
Posts: 1589
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic