In short for application or web servers, stateless is good, stateful is, um, a concern.
Stateless beans can accept a request, handle the request, send a result, and then forget all about the user. The bean is then ready to handle the next request on behalf of another user.
But sometimes you must keep some information for the life of the user's session. Authentication information and shopping carts are a couple obvious examples. Having the server keep any information on behalf of the user in memory can limit the number of simultaneous users.
There are many places to stuff such stuff:
In
Java or COM objects in memory
In server "session" storage
In a cookie
In hidden fields on the HTML page
In an XML data island on the page
In JavaScript on the page
Encoded on the URL
In temporary session storage on a database
On the real database of record
I bet folks here can think of more than that.
Stateful Session Beans were invented to save the developer some effort. The container can manage the state for you. If using too much memory swap to some external storage, restore it when the next user request comes in, synchronize between clustered servers, etc. The container can implement new techniques over time without changing application code.
Well, that was typically long for me. Did it help?