File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes EJB Stateful Session bean vs HTTP Session Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "EJB Stateful Session bean vs HTTP Session" Watch "EJB Stateful Session bean vs HTTP Session" New topic

EJB Stateful Session bean vs HTTP Session

chris lambrou

Joined: Feb 12, 2011
Posts: 2
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.

Jeanne Boyarsky
author & internet detective

Joined: May 26, 2003
Posts: 33124

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

[OCA 8 book] [Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Ajay Singh Rathore
Ranch Hand

Joined: Mar 27, 2008
Posts: 64
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.

Joe O'Toole
Ranch Hand

Joined: Mar 02, 2009
Posts: 51

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

ntumba lobo
Ranch Hand

Joined: Oct 21, 2008
Posts: 180
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
Ranch Hand

Joined: Mar 02, 2009
Posts: 51
OK - but if you have an application which has both a web server and an ejb server, where should you persist client session information?

ntumba lobo
Ranch Hand

Joined: Oct 21, 2008
Posts: 180
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
Ranch Hand

Joined: Sep 26, 2011
Posts: 63

Chris, I think you should read this:

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.
    I agree. Here's the link:
    subject: EJB Stateful Session bean vs HTTP Session
    It's not a secret anymore!