EJB Stateles and statefull from servlet point of view

[Kiril Nugmanov]

Hi all,

I'm wondering about usage of Statefull EJB in servlet/JSP. As I understand servlets aren't thread safe (only HTTPSession, httpServletRequest and local variables are) so:

using DI for servlet is worthless

access statefull via stateless won't work

But while serachig the example of usage statefull EJB I've found following sollution: put obtained statefull EJB into HTTPSession and afret that use saved object. But the same I can do with stateless. While I'll be holding object in session there is no any advantage of Statefull against stateless. Am I right?

[Davide Crudo]

...The rule is that whenever possible, forget about Stateful beans (for obvious reasons, like allocating precious resources to just one client instead of sharing them...)

but there are cases you will need them, like:

1) You want to maintain the transaction open during subsequent calls. Regarding this i was reading a while back, an example of an airline booking. If you plan to book 3 flights, and you want those flights to either be booked all together, otherwise the transaction should fail, then you need a Stateful bean, so you can rollback the transaction in case of problems (you can keep the transaction open between method calls using an extended persistent context)

2) As you mentioned, to keep state between calls, i.e. a shopping cart

3) You need a Stateful session bean if you want to implement the SessionSynchronization interface. The reason you may want to implement it is in the case as you mentioned when you have a Servlet. If you access the HTTPsession to set your own variables, you might need to use SessionSynchronization to keep those calls consistent. You can read how it works here.

Dave

[Mihai Radulescu]

Hi guys,

From my point of view the servlet and the stateful beans colide because of the stateless nature of the servlet. There is only one servlet instance and severals requests this brings at least two major problems :

if the the logic is spread over request can be that one request may close the bean (by calling one of its remove methods) and the other requests still want to work with the bean which goes invalid

if more users interact with one servlet and the statefull bean is used to store user specific information the all the user will share the same information, which in some situations (like shopping list) may be unpleasant.

Kiril, why do you think that using DI for servlet is worthless ? This is the only way to obtain resources. Without DI you don't have any other possibility to get a bean instance.

Regards
Mihai

[Davide Crudo]

@Mihai

I understand your concern, but you can find the Sun Duke's Bookstore application example
where they show how to build a servlet to handle multiple clients using the HttpSession object,
you can find the specific page here and the Start of the project here.

Dave

[Kiril Nugmanov]

Hi all,

@Mihai Radulescu: as You mentioned servlets by nature are stateless and if I would try to use DI for statefull EJB - I will allways get new("empty") EJB. Thus

Davide Crudo wrote:
...The rule is that whenever possible, forget about Stateful beans (for obvious reasons, like allocating precious resources to just one client instead of sharing them...)

[Mihai Radulescu]

@ Kiril : when you call a business method on a stateless bean then : if the beans is not associated with the session a new one is created and if not then the actual bean is used (to mentain the conversation). The problem is that every time when you do a JNDI look up for a stateful bean a new session is created. So if you keep doing JNDI lookups you will continuous get new sessions and new stateful beans. The solution with the HttpSession is preferable because the session is specif to the user, otherwise you need some problematically way to keep together the user and its specific changes.
So, to conclude the reason for "new empty stateful beans" is not the servlet's stateless nature, it is the JNDI look up mechanism for stateful beans.

Regards
Mihai