EJB Stateful Session bean vs HTTP Session

[chris lambrou]

I saw a question in one of the mocks that says
"You are in charge of developing an e-commerce web application, the client expects high traffic volumes and the security is of essence.
Which user session management strategy would you choose?"

I chose "Save user session in an EJB stateful session bean object " but the correct answer was "Save user session in an HttpSession object"

What does everyone think about this ? To me, the "high traffic volumes and the security is of essence" requirement point to an EJB-Centric solution.

Thanks,
C.

[Jeanne Boyarsky]

Chris,
Statefull EJBs are known not to be scalable. This is why they don't recommend them for high volume.

[Ajay Singh Rathore]

Apart from not being able to scale well, if you have set up a cluster for scaling out then replication of SFSB has more overhead associated with it then replication of http session.

Ajay
SCJP, SCDJWS, SCEA part 1

[Joe O'Toole]

Hi

I was reading some Sun/Oracle documentation on this and basically what I understood the approach was to use the enterprise bean to maintains states assuming you are using ejb's.

If your not using ejbs then use the http session object.

They did not appear to mention any concerns regarding the performance of SFSB's. Hence very confused with this one

Thanks
Joe

[ntumba lobo]

well you may not always have the choice.
If you are a non web application and you need to maintain client state, using stateful session beans may be your only choice if you dont want to implement something custom.
In a web application it is true that HTTP session is preferred over stateful due to perf impact and poor scalability

[Joe O'Toole]

OK - but if you have an application which has both a web server and an ejb server, where should you persist client session information?

Thanks
Joe

[ntumba lobo]

It depends on the requirements of your application.

I would say that for a small to medium size app if you have web clients and non web clients accessing your business logic I would
have the client state stored in the EJB layer (SFSB). That way no duplication, your client state is managed in one single place for all your clients.
Performance is the only driving force of an architecture, simplicity is also to be considered.

Now if you have a significant higher traffic coming from the web, you may consider having the client state in the web layer calling some SLSB for busines logic.
The low traffic from the non web clients would still have their state managed in the EJB layer SFSB. The impact of the SFSB on perf is less significant due to the low traffic.

[Eduardo Mineo]

Chris, I think you should read this:

http://onjava.com/onjava/2001/10/02/ejb.html

The most important part is this:

When SFSBs should be used in web systems

Systems that have JSP/servlet front-ends should use HttpSession objects to store session-oriented state on behalf of a client. Applications that manage an HttpSession object and an SFSB for a single client wind up duplicating effort that does not need to be duplicated. There are two reasons to use an SFSB in conjunction with an HttpSession object:

Your application server does not provide cache management of HttpSession instances and your system is expected to have a large number of concurrent clients. Containers for SFSBs can activate and "passivate" the state of instances to and from a secondary store. This allows a container to create an upper limit to the number of instances that will exist in memory at any given point in time. The number of concurrent clients can exceed the limit of SFSB instances in memory because the container can swap idle instances to and from the secondary store. The container will never allow more than the limit of SFSB instances to exist in memory, subsequently placing all additional instances into the secondary store. This provides a greater level of scalability to the system through effective memory management.

Many application servers provide similar cache management of HttpSession objects. Because HttpSession objects are similar to SFSBs, they can also be made passive and active. Cache management behavior of HttpSession objects is not required as part of J2EE and is considered a vendor value-add. If your application server does not support HttpSession cache management -- and you need to control the total number of session-oriented instances in memory at any given time -- you should place the bulk of your session-oriented data in an SFSB instead of an HttpSession object. You will still need to maintain an HttpSession for each client, but the only item in the HttpSession should be a reference to the SFSB for that client. If the only item in the HttpSession object is a reference to the SFSB, the amount of memory consumed by each HttpSession object is minimal and cache management of these instances is not needed. The bulk of memory consumption will occur within the SFSBs, which have a standardized strategy for allowing a container to perform cache management.

Your session-oriented objects need to receive notifications on the lifecycle of the transactions they participate in. SFSBs can implement the SessionSynchronization interface. The SessionSynchronization interface contains three methods that a container invokes as a transaction migrates through the lifecycle the SFSB is participating in. An SFSB might implement the SessionSynchronization interface as a way to return the data of the SFSB to its original state whenever there is a transaction rollback. HttpSession instances do not have a mechanism that allows them to receive transaction notifications. This means that any data that is modified in an HttpSession during a transaction will not be reverted if the current transaction is rolled back. All changes to data in an HttpSession object are always durable despite the outcome of any executing transactions. If this behavior is not appropriate for your system, placing all data into an SFSB instance that implements SessionSynchronization will give you the appropriate behavior.

And make sure you really understand what "client" means when you are talking about this subject. In a standalone application that connects directly to the EJB Container, the user is a direct client of your Stateful Sessionbean, therefore it's easy to keep the state between calls. But when the scenario moves to a web application, the user client (web browser) is an indirect client of your Stateful Sessionbean. The direct client, in fact, is the web container, so, you have to think about how you will link users(browsers) with stateful sessionbeans stubs in order to assure each user has its own instance of stateful bean. And that would be storing the reference in an HTTPSession.