Adding to duffymo advice; There are a few additional considerations for using a beans vs session using an HTTP session.
An HTTP session basically has a map such as a structure. It is directly accessible to all threads (requests) that are part of the session. This allows you to manipulate several elements with a relatively unsafe action. You can synchronize the session itself, but this is a dangerous operation that can potentially block your entire application. An HTTP session allows you to declare event listeners that trigger any modification to an http session.
A bean state session, of course, has a bean structure. It has a kind of automatic synchronization function, since only a thread can be active in a bean at a time. Through annotations, you can declare whether other threads are waiting (and if so, for how long) or immediately throw an exception in the face of concurrent access.
In cases where there is usually only one HTTP session per user, one user can use several sessions with beans at the same time. A special advantage of a beans state session is that they have a mechanism to passivate their state after some timeout, which can free up your server’s memory (of course, due to disk space). The beans session does not have a direct type of event listener that has an http session.
I think the original “session” aspect of the beans state session was to maintain a session with remote non-web clients (Swing, another AS, etc.). This is very similar to the fact that the http session was created to support the session with remote web clients. Since a non-web client can request and hold multiple proxies for a beans state session, the web analogy is actually more like that of the recently introduced conversation scope .
In the case where remote web clients talk to the server, where the server internally talks to the session with the bean state, the concepts overlap greatly . The remote web client only knows about the http session (via JSESSIONID) and nothing about the session with the bean state. Therefore, if the http session was lost, you will usually not be able to reconnect the remote client to a specific session with a bean state. Thus, an HTTP session is always the leading one in this case, and you can also store your shopping cart items inside a single (http) bean session.
There is one specific case where a beans state session is useful for internal communication, and if you need a JPA extended persistence context . This can be used if, for example, the locks on the joints should last between requests (which is probably convenient for a shopping basket, if you have a limited stock, and you do not want to resist the user with the message “out of stock” as soon as he checks) .