Session management approach – choice vs. discipline

May 23, 2007

Bring up the topic of stateful and stateless applications and you can guarantee to get a house divided, almost equally on both sides. There are die-hard proponents of statelessness (and frameworks to support it;Spring for one) and those that support stateful behavior(and frameworks to support it; JBoss Seam for one) .

This leaves the average developer confused – is holding state good or bad? The answer is different : It is inevitable in circumstances and avoidable in certain others.

A regular web application normally contains state while service calls in the integration or infrastructure layer may not. Often the latter is designed that way i.e being stateless for sake of scalability and fail-over.

An often used approach to maintain state is a user session. The most common choice is the HttpSession. Cluster-aware application servers handle replication of these sessions. In-efficiencies in session replication are often cited as reasons to move to a stateless design or look for alternative means for replication. Lets take a look at common approaches to managing user sessions before we decide on the merit of this move. Session replication choices:

  • No replication. No fail-over. Sticky behavior is the only choice in a redundant server deployment.
  • In memory replication. Default behavior in J2EE application servers.
  • DB based replication. Optional behavior in .Net and Ruby On Rails platforms.

Take any approach and you can find people give you many reasons why not to use them. Some of reasons can be : lopsided load in case of stickiness, inefficient in-memory replication and cluster license cost(3 times more) in case of in-memory replication and increase in DB I/O in case of DB based sessions.

We might do better by addressing the problem before trying to find more efficient solutions. Control over what is considered as valid state and the size of the state object graph matter more. I follow these principles/practices when handling state in my application. Some of them are not new and are in fact best practice recommendations for performance, robustness and overall hygiene of the system:

  • Store only key information in the session i.e only minimal data with which you can re-construct the entire session graph.
  • Store only domain model or equivalent data objects. Avoid objects that hold behavior. An easy way to implement this is to wrap session access with a layer that entertains say only XSD derived objects, which effectively cuts out behavioral class instances.
  • Set a limit to the size of the session i.e avoid large session graphs. The session wrapper can ensure this.
  • Persist session only if dirty. Applies to cases where there is container support and in custom session persistence implementation.

An application that follows all of the above would rarely need to debate on the cost of maintaining state via sessions – in memory or in the DB.

DB based persistence is considered expensive and a mis-fit to store transient data such as user session information. However, interestingly frameworks like .Net and Ruby on Rails(RoR), that matured later than J2EE, provide this as an option. In fact, it is the default in RoR, if Iam not wrong.

Recently I had the choice to architect a SOA based platform to build applications on top. We wanted the core services to be stateless to easily scale out when required. Naturally we preferred the application servers to NOT be clustered and be load balanced instead. The applications built on top had to contain minimal state however. We also decided to mask session management from the consuming applications and implemented session persistence and therefore recovery using the DB. While there were initial apprehensions about DB I/O bottlenecks, adopting the principles described above helped us tide over the issue. The end-applications have been in production for a year now. The logic we used in favor of DB based sessions was this : nature of DB access for say 100 concurrent users would mostly be READ with the odd case of a WRITE(i.e when session gets dirty). 100 reads of small sized records using an index on a table is extremely fast as there are no concurrency or transaction isolation issues as each read is for a specific record independent of the other. Anyway, we have the option to switch back(courtesy the wrapper over session management) to Http sessions and clustering if performance sucked, which hasn’t happened till date.

To sum it up : the debate between Stateful and Stateless applications and consequently that on the most efficient session persistence/replication mechanism is really a matter of choice if session is handled with some discipline in the application.


10 Responses to “Session management approach – choice vs. discipline”

  1. Riccardo Says:

    Nice article; short but informative.

  2. yellaiah Says:

    Excelent and informative.

  3. Janardan Says:


    I got really good information from this article.
    But, I am having difficulties in below mentioned point can you please explain it.

    Store only domain model or equivalent data objects. Avoid objects that hold behavior. An easy way to implement this is to wrap session access with a layer that entertains say only XSD derived objects, which effectively cuts out behavioral class instances.

  4. Janardhan,

    Residual state between multiple user-interactions within a web application is mostly stored as structural data.
    Consider examples like a shopping cart or logged-in user profile. The domain model in this case may be a ShoppingCart class or a User class that might hold other data attributes in the form of classes like Item, Locale e.t.c. Each of these objects are data containers.
    You would not want to store objects like ShoppingCartCheckout in the session i.e objects that contain behavior. Also these objects can hold references to resources like DataSource(for DB persistence) say, which anyway need not be saved onto the session as it can be looked up on demand. See my first point on storing only minimal information using which others may be derived/re-constructed.
    XSD is a great way to define data structure – content type, references, cardinality e.t.c. You cannot define a javax.sql.DataSource easily in an XSD (well, you can as an un-typed Object, but should not). Therefore defining a data model using XSD and then deriving the Java object equivalent using one of the JAXB tools like Castor would ensure that you can effectively weed out behavioral objects from appearing on sessions. You can create a simple hierarchy for these XSD derived objects and ensure that the session wrapper checks for the instance type when a call is made by the client to set/update an object in the session.

  5. Janardan Says:

    Hi regumindtrail,

    I got clear idea about it. Thanks for this explanation with example.

  6. jj Says:

    Can you please put some thoughts on – Single sign on and its impementaioj using java & GSS in a simplified way…though there a lot of stuffs availabe on net, I prefer the way you pictorize things


  7. JJ,

    What is the scope of the SSO that you are referring to here? Is it limited to applications hosted on a single infrastructure i.e software platform within an organization? Or is it more far-reaching so as to enable SSO across partner enterprises/systems that work in a federated manner?

    The first one should be easier while the latter would require trust, identity management and standards like SAML and secure protocols.

    In the former, all applications are often built using the same(or similar) programming languages, access the same user base(authentication), access control base (authorization) and may even be co-deployed on the same infrastructure. This lends itself well to session token based SSO where issues like session-hijacking can be addressed using cookies, spoofing can be addressed by tying authentication and authorization together via the principal stored in the session e.t.c.

    For the latter, concept-wise something like the “Liberty Alliance” project may be suitable to establish the standards between the enterprises. Technologies like JAAS or Java GSS might then be an implementation choice.

  8. jitendra Says:

    quite heavy……………article
    though not convincing.
    i expected more about the topic….
    please include more examples and relevant diagrams.

  9. Subramanian Says:

    A question regarding session management. When we create a swing based application to access EJB’s through a business delegate i.e Swing (HTTP)-> BD (RMI)-> SFSB/SLSB – would it be appropriate to have the session stored in Swing process and use SLSB instead of adopting SFSB ? Against the overhead of having to pass business state for each request isnt the application is likely to scale well ?

  10. Subramanian,

    From a scalability standpoint, IMO storing session on the Swing side would be preferred as your server side can then be entirely stateless and the ability to scale out is virtually limitless.
    On the contrary, if the session data is really big, it poses a significant overhead on the network and introduces an I/O overhead that could affect performance of the application. The decision therefore is answered by a question on what is needed – scalability or performance. You might also want to consider if the Swing application is the only client to the server application and therefore moving session management out does not affect other clients.
    Finally another food for thought can be – how often is your session data updated. If it is quite often, the overhead of data passing between server nodes(due to clustering of SFSB) might be close to the overhead of passing the data along with each request from the Swing client to the server.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: