File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes EJB and other Java EE Technologies and the fly likes Stateful Session Bean Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Stateful Session Bean" Watch "Stateful Session Bean" New topic

Stateful Session Bean

Raj Mohan
Ranch Hand

Joined: Sep 26, 2000
Posts: 73
I have a very basic question about this stateful session beans. I have a stateful session bean and servlets.
Servlet A creates the shopping cart season bean and add some items to that. Now Servlet B has to get the reference. How do I do that?. Do I have to keep the reference in Http Session so my servlet B can get it? In that case, why should use the Stateful session bean?.
Dave Landers
Ranch Hand

Joined: Jul 24, 2002
Posts: 401
You have to keep the reference somewhere.
Once you create a stateful session bean, you have to keep using the reference you got from the Home in order to access it. There is no way to "look up" a stateful session instance like you can do with an Entity finder.
The http session is as good a place as any to stuff the ejb handle.
Or, you could just keep the shopping cart information itself in in the http session. This is probably easier than using an EJB, but your data is in a different place - web-tier rather than ejb-tier. That can have an impact on performance and scalability - but the answer depends on your deployment, load, etc.
Or, you could use an Entity Bean to persist the Shopping Cart. You can can call a finder method when you need to retrieve the cart. This might be a bit more work, as you now need shopping cart tables in your database, but your users shopping carts can be saved even if they loose their session (i.e. they log out or time out, etc).
Byron Estes
Ranch Hand

Joined: Feb 21, 2002
Posts: 313
Originally posted by Raj Mohan:

Do I have to keep the reference in Http Session so my servlet B can get it? In that case, why should use the Stateful session bean?.

As the previous replier noted, you need to keep a reference somewhere, or save the handle so you can "recreate it" later. The session is a logical place to hold this. If you only need to pass it to another servlet in a chain responding to the same request, you can probably add it as a parameter/attribute to the request and just forward responsiblity to the next servlet.
I don't think anyone responded with why you would use a stateful session bean if you had to store a reference to it into the session.
I think there are a number of "potential" reasons, but as usual it really depends on the needs of the application.
-transacational capbaility
-security mechanisms
-performance (...pooling-activation/passivation)
-life cycle management of the objects/data in the form of the stateful EJB is provided for you.
If the application is simple, you don't need transactions, security is simple and the data you need to store is simplistic, maybe not alot of behaviours, you might decide to use another mechanism.
I have in the past (...with non-java apps mostly) stored by session data in a database. I did this because my business layer logic had to be used my many different presentation layers that supported various devices, all of which were wireless constrained devices, some of which didn't support cookies, etc. I'd assign a UUID to each new session store the session info in the database related to the UUID and pass around the UUID as a token.
Lots of ways to do the job, each has it pro's and con's. All you can do is look at the specific situation and evaluate each in licght of the business need.

Byron Estes<br />Sun Certified Enterprise Architect<br />Senior Consulant<br />Blackwell Consulting Services<br />Chicago, IL<br /><a href="" target="_blank" rel="nofollow"></a>
Raj Mohan
Ranch Hand

Joined: Sep 26, 2000
Posts: 73
Thanks Dave
Thanks Byron
I agree. Here's the link:
subject: Stateful Session Bean
It's not a secret anymore!