Client Side Session Management…


Ok this is an old hobby horse I’ve reeled out many times, and now that I’ve got round to starting a blog what better place to find a permanent home for this old equidae.

The traditional way of managing sessions is on the server with the application container managing session keys/data. As a front end developer your job is simply to populate the session data as it is capatured on screen, the application container does the rest for you. The application container should offer different mechanisms for replicating session data across servers, thus providing session failover. It should also optimise the storage of the data itself, and manage the session keys with it’s own policies for clearing out dead sessions.

The problem with this model is that it is simply not that easy. Some of the issues that need further consideration are: Memory optimisation, Long vs Short Running sessions, Server Redundancy:

When storing data in sessions, the data element is normally given a name, generally this is something meaningful that a developer can use to make code more readable. However these name themselve take up memory. Whilst this may not seem a huge issue with the amount of memory in servers these days, we’ll see later in the post why optimising memory for sessions is necessary. So one improvment you can make is to implement hashing to reduce lengths of names used in code. Another technique would be to use compression for the actual session data especially for large free text fields.

Generally there are two types of sessions long running or short sessions. Typically internal applications such as call centres will have users that log-in in the morning use an application all day, and log-off at the end of the day. Such applications if not designed efficiently often do not release session data during the session, this can have the issue of builiding up huge memory requirements per user of the application. Prior to memory depletion, performance degradation will be the first issue as memory is swapped in/out of disk, followed by out of memory server crashes. Hence developers need to consider what memory should be held and when to release this memory. Short running sessions with mass users e.g. shopping sites, tend to have less per user storage requirements but many more users, creating a large memory requirement overall. In this scenario identifying dead sessions is paramount to reduce memory redundancy. Other optimisations include identifying session data that is used not per user but globally across all sessions, and caching one instance of that data rather than load it per user.

So it is for reasons like the above why client side session handling make so much sense, if only it was supported as standard by the browser rather than having to use hidden fields. Quite simply client side session management is a means of keeping data in the browser rather than on the server, therefore reducing the memory requirements and extra processing that an application container has. It would not only reduce the cost of the server you’d need it would also improve performance of the client application also, more so than the use of Ajax.

I can’t think of any downsides to this approach whilst the upsides are huge. What do you think?


Digg!

Advertisements

Tags: , , , , , , , , , , , , , , , , ,

8 Responses to “Client Side Session Management…”

  1. Martin Doyle Says:

    Only just come across this blog … very enjoyable and thought-provoking!

    Regarding the question posed at the end, and I mention this more from a devil’s advocate point of view, there’s something to be said for maintaining state not on the client, as it potentially means that the client can go back to the website and pick up where they left off.

    Admittedly, for shopping sites, this is not likely to be a problem, but when dealing with a complex web application, that could be the difference between frustrated or happy end-users when their browser crashes or their internet connection dies temporarily.

  2. Dharmesh Mistry Says:

    Thank Martin, and yes you’re right where you need persistance. If a user is quite happy to provide some registration details so that session data can be persisted and retrieved later then yes it’;s advantageous to store on the server.

    However temporary storage on the server remains questionable as even with this approach coming back to a session after timeout or lost connection should result in the session store having been cleared (even just for security so that somebody doesn’t try to access a site whilst the actual user is not at their PC).

    In fact again client side session management can have the advantage that data is not lost even when the connection has temporarily been lost, by allowing the user to keep their browser open and re-post data later, another great advantage ;o)

  3. Martin Doyle Says:

    Good point about the temporary loss of connection, and yes … security must always be paramount, particularly when it comes to sites involving any amount of money!

  4. Why create portals when you can create a composite application? « Facing up to IT Says:

    […] I mentioned in an earlier post on usability issues, next generation portals will be unlikely to provide useful access to […]

  5. Tomas Says:

    Isn’t that called Cookies? 🙂

    • dharmeshmistry Says:

      Yes you can use cookies to achieve this, however you are constrained by users that don’t allow cookies.
      By having this supported in the browser you could potentially also share data with other applications, achieving functionality provided by portlets (Portlet to portlet communication) without the overhead of a portal server.

  6. Session Management – Part 1 « Solution Hacker Says:

    […] servers via session replication. Not Good! Should we reconsider storing session in client? This article talks about […]

    • dharmeshmistry Says:

      Good article and thanks for the reference. Have you started looking at HTML5 yet? New features of HTML5 will in my mind make client side session management almost inevitable for most applications ;o)

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s


%d bloggers like this: