Software Twist – Adrian Tosca Blog

Handling Enterprise Web Application Sessions

Posted in Patterns and Practices, Software Architecture by Adrian Tosca on 2011, January 30

The basics of web session handling

Web server session is a well-known mechanism used in web applications to handle state in connections for an environment that is by very nature stateless. At its base, the HTTP protocol has no notion of state, is just a request-response protocol. Unfortunately the stateless protocol has some issues to cope with certain type of applications that need persistent information over a number of request-response cycles.  A shopping cart is an example of the necessity to save some temporary information over a number of request-response cycles until the check-out is finalized.

Over the years, there were many attempts to improve the communication environment with state information: cookies, information saved in the delivered page and posted-back with the form (a mechanism perfected by Microsoft ASP .Net) and of course the web session.

Web session has many mode of implementations but all have in common that some data is saved on the server and there is a mean of  identifying the data between requests. By using this identifier the data can be retrieved with the next requests. Of course the identifier still needs to be persisted between the requests as is described later.

Mechanisms for saving data on the server

  • Data saved in files

This is a simple way to persists data on the server, the data is serialized in simple files and the name is used to identify  it. This mechanism is often used with the PHP framework. The mechanism is very simple to implement and use but is not safe enough for some uses.

  • Data saved in the same process as the server component

The server component that is processing requests has usually a long living time on the server and can hold the data between requests in memory. Of course a crash of the component will cause the loose of all saved data.

  • Data saved in a dedicated process on the server

This is a variation of the previous method where data is saved in a dedicated process, specially build to handle session data and thus more robust and more unlikely to crash. This does not come for free as it incur some performance penalty because of the need to send data to another process. The data is still lost if the server crashes or needs a restart.

  • Data saved on a separate server

The data is still saved in memory but this time on a separate server or farm of servers. The cost of transferring data over network can be pretty high but the reliability might be more important.

  • Data saved in a database

This method avoid loosing the data but again some performance must be traded in. The performance cost of saving the data to the database might be high but the permanent storage and transactionality might deserve the trade off.

Most current web frameworks including J2EE and .NET Framework have implementations of all these mechanisms.

Mechanisms for identifying the data between requests

  • Using a cookie

A short identifier that uniquely identify the data on the server or more usually the entire session is saved as a session cookie. The cookie  is persisted on client side and sent with each requests to the server usually until the client application that handles the series of requests is closed.

  • Using the URL

The identifier is directly written in the URL of the page. The URL is parsed on the server and the extracted identifier is extracted to identify the data or the entire session.

  • Using a hidden field

The identifier is written in a hidden HTML form field and sent back to the server when a new request is made.

Most current frameworks support all these mechanisms. The cookie is usually the default mechanism but in some cases the other mechanisms are used as a fall back method.

Handling the web session in a more powerful way

All the mechanism covered above are used to simply save some data over a series of requests. The data can be anything and the frameworks do not care of its meaning. The framework that implements the web session mechanism just saves a bunch of data and return it when requested. A obvious limitation is that the session is, well, just a session, limited in time by the time the client is up and running.

Have you used Amazon to buy something? It is interesting how they handle the shopping card data. Instead of saving this data for the duration of the session (as long as your web browser is opened for example) they persist it indefinitely. This is a shift from the classical way of doing things but a very powerful and significant one. Instead of giving the impression of something temporary they basically tell you: “this is your place, you can do anything you want and we will keep your data exactly as you left it until you come back!”.

But this approach also need a shift from the usual session handling. Because to implement a permanent “session” the application needs to understand the data. Imagine for example what would happen if the shopping cart saved an item with 100$ price tag and after a month and several price reductions the user  is coming back and buys the product with the original price: he will not be very happy if he finds out!

The way to handle the permanent “session” is to not treat it like session but as normal application model data. If you are using a relational database to persists the application data you just need to have a couple of more tables to handle the “temporary” data. In the case of the shopping cart example you can have a table with reference to product, the original price and date of the last access. The price can be directly retrieved from the current product price when the shopping cart page is displayed.

But this mechanism can be used not only for fancy web sites but also for normal enterprise class applications. Complex applications usually need a number of steps to enter or modify data. Filling up this data can take quite some time, it can be very frustrating to have to do it at once especially when it happens that the network is temporary unavailable or the damn browser just needed a rest. Imagine you can have a web enterprise “session” mechanism in place and any data that is saved, presumably using several complex forms, is treated as temporary data until the user commit it. The final validation can take place at the last stage when all the data is available and the user has the chance to correct some of first information entered before the last save is performed.


Comments Off on Handling Enterprise Web Application Sessions

%d bloggers like this: