• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Best practice for stateless session bean in a servlet

 
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all. I am experienced in Java, specifically with JSPs and servlets. However, I am relatively new to EJBs. I am working on a app that uses EJBs in a relatively simple way. Basically, either an "Action" class or a Servlet invokes a stateless session bean (no entity beans involved) to remotely either retrieve or update a database value.

My question relates to the servlet implementation. I have seen various examples from online tutorials and books that use this approach:

1. Declare the remote interface as a member object; e.g.:

2. In the servlet's init() method, instantiate that remote interface instance, like:

3. In subsequent doPost(), doGet(), or service() method calls, use that remote interface instance to do stuff.

My question is this: is it a good idea, in a production app with potentially busy traffic, to use a single session bean like that? The servlet could field many requests near-simultaneously, but each request would need to use the same session bean. My gut tells me that this approach is wrong, that the session bean should not be essentially a singleton member variable; rather, a new instance should be called within each doGet()/doPost()/service() method call. That seems to be the whole point of EJBs; the container would manage how to reuse beans, when to create new ones, etc. But I thought I would check, since I have seen different tutorials use the approach illustrated above.

Do any experts have any advice or insight? Thanks in advance!
[ September 02, 2004: Message edited by: dave taubler ]
 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I know that for a stateful bean, what you have would be wrong. But I think for a stateless bean it is okay.

The main point to remember is that a stateless session bean is not backed by a single session bean object. It is backed by a pool of objects. Each time you call a business method, a bean is pulled from the pool, the business method is executed, and the bean is put back into the pool to wait for the next request (unless something bad happens). So multiple calls on a remote interface will not turn into multiple calls to the same instance of the bean.
 
dave taubler
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Brian,

Thanks, you make a good point. My mistake was assuming that a stateless session bean instance was backed by a single object. It makes sense now.
reply
    Bookmark Topic Watch Topic
  • New Topic