Question

it’s my first question here and I hope that I’m doing it right.

I need to work on a Java EE project, so, before starting, I’m trying to do something simple and see if I can do that.

I’m stuck with Stateful Session Beans.

Here’s the question :
How can I use a SFSB to track an user’s session?
All the examples that I saw, ended up in “putting” the SFSB into a HttpSession attribute.
But I don’t understand why!
I mean, if the bean is STATEFUL, why do I have to use the HttpSession to keep it?

Isn’t an EJB Container’s task to return the right SFSB to the client?

I’ve tried with a simple counter bean.
Without using the session, two different browsers have the same counter bean (clicking on “increment” changed the value for both of them).
Using session, I have two different values, each for every browser (clicking on “increment” on Firefox, added one just to Firefox’s bean).

But my teacher told that a SFSB keeps the “conversational state with a client”, so why it doesn’t just work without using a HttpSession ?

If I understood correctly , isn’t using HttpSession with a SFSB the same of doing it with a SLSB instead?

I hope that my question(s) is clear and that my English is not that poor!

EDIT :
I’m working on a login system.
Everything goes fine and after completing the login it takes me to a profile page that show user’s data.
But reloading the page makes my data disappear!
I’ve tried adding HttpSession while logging but doing in this way makes the data stay even after the logout!

Answer 1

A Stateful Session Bean (SFSB) has to be combined with the HTTP session in a web environment, since it’s a pure business bean that itself knows nothing about the web layer.

Traditionally EJBs even mandatory lived inside their own module (the EJB module), that couldn’t even access web artifacts if they wanted to. This is an aspect of layered systems. See Packaging EJB in JavaEE 6 WAR vs EAR for more information about that.

The original clients for Stateful Session Beans were among others Swing desktop applications, that communicated with the remote EJB server via a binary protocol. A Swing application would obtain a connection to a remote Stateful Session Bean via a proxy/stub object. Embedded in this proxy is an ID of some kind that the server can associate with a specific SFSB. By holding on to this proxy object, the Swing client can make repeated calls to it and those will go to the same bean instance. This will thus create a session between the client and the server.

In the case of a web application, when a browser makes an initial request to a Java EE web application it gets a JSESSIONID that the server can associate with a specific HTTPSession instance. By holding on to this JSESSIONID, the browser can provide it with each followup request and this will activate the same http session server-side.

So, those concepts are very similar, but they do not automatically map to each other.

The browser only gets the JSESSIONID and has no knowledge about any SFSB ID. Unlike the Swing application, the browser communicates with web pages, not directly with Java beans.

For mapping the client’s request to a specific stateful session bean, the EJB container only cares about the ID provided via the SFSB proxy. It can’t see if the call happened to originate from code in the web module and can’t/shouldn’t really access any HTTP contexts.

The web layer being the client code that accesses the SFSB must ‘hold on’ to a specific proxy reference. Holding on to something in the web layer typically means storing it in the HTTP session.

There is however a bridge technology called CDI that can make this automatic connection. If you annotate your SFSB with CDI’s @SessionScoped and obtain a reference to the SFSB via CDI (e.g. using @Inject), you don’t have to manually put your SFSB into the http session. However, behind the scenes CDI will do exactly that anyway.