This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes EJB and other Java EE Technologies and the fly likes Best practice for stateless session bean in a servlet Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Best practice for stateless session bean in a servlet" Watch "Best practice for stateless session bean in a servlet" New topic
Author

Best practice for stateless session bean in a servlet

dave taubler
Ranch Hand

Joined: May 15, 2001
Posts: 132
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 ]

Dave Taubler<br />Specializing in <a href="http://taubler.com/articles/" target="_blank" rel="nofollow">Java and Web Development</a>
Brian Tinnel
Ranch Hand

Joined: Aug 25, 2003
Posts: 69
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

Joined: May 15, 2001
Posts: 132
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Best practice for stateless session bean in a servlet