java jakarta-ee ejb-3.0 stateless-session-bean stateful-session-bean

How GlassFish maps client requests to sessions

With EJB (3.x) you have a choice of Session Beans: @Stateful and @Stateless. If I understand the basics behind these two options:

@Stateful - Each user/client gets their own and is thus typically not pooled; maintains state across multiple requests
@Stateless - Does not maintain state between requests and thus is usually pooled so each new client request gets a fresh bean

My core question here is quite simply, however there are several mini-questions that I have that are tangential to it: how does my POJO design differ between @Stateful beans vs. @Stateless? In other words, if I have a HelloWorld bean that implements the Hello interface, how does that POJO's design change depending on whether I want it to be stateful or not?

Tangential to this:

What different restrictions does the app container (in my case GlassFish) impose upon the EJB depending on whether it is stateful or not?
In the case of @Stateful, how does a client-side request from the same user/client get mapped to the correct bean (the one maintaining the client's state from a previous request)?
When do session beans die? I assume its immediately after the request is done for @Stateless, but no clue for @Stateful.

Thanks in advance for any clarity here.

Solution

Regarding the core question "how does my POJO design differ between @Stateful beans vs. @Stateless":

Your hello world example is an excellent example of a @Stateless session bean: the implementation has no state (no class instance variables). It makes no assumptions about state. If you do need "more information" in a @Stateless bean look it up, (re)compute it, etc. If you break this rule and define instance variables on the bean, you have no assurance that the information will be what you expect it to be on each invocation of the bean: don't do it.

Your design of a @Stateful bean would keep internal state (class instance variables) that the container will preserve for the life of the bean; the bean must be Serializable. There are very real run-times costs (memory, and managing the issues around your second tangential question, particularly in a clustered environment) associated with keeping the bean around for the life of the session - so use this only as appropriate (which justifies the existence of @Stateless beans).

For example, consider a simple sign-up page: enter user name, email address, etc, followed by "are you sure"? A @Stateful bean can preserve this temp information until you're ready to submit it to a back end.

Google for examples; here's one: http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/6/html/Beta_Documentation/Stateful_Session_Bean_Example.html

HOW the client-side gets mapped to the correct @Stateful bean is truly implementation dependent (not spec'd), however you can expect that it's managed analogous to how your Servlet Session information is maintained. That said, don't confuse the Servlet Session with a @Stateful session - they're not the same thing at all.

For Java EE 5/6 in your @Stateful bean annotate one method with @Remove, and when your client calls that method it'll be released back to the ether. Outside of that, as long as you hold a reference to the @Stateful bean (i.e. in your Servlet Session) you can expect that @Stateful bean to be around when you need it.