hi, 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?. Thanks Raj
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).
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. Regards,