Question

I have been researching the implications of setting up a distributed session environment, and wanted to ensure I was not missing any major points.

With respect to developing apps that will run in a distributed session environment, the main development issue I have identified is the loss of data that may be kept in the session. Obviously everything would have to be serialized or converted to stateless (or a combination of both) which could be a significant undertaking for any apps already coded for heavy session use.

Are there any other potential issues or implications I should be aware of?

Edit: To be more specific (and as an example), I’m referring to Java web application server-side sessions in a servlet container environment.

Answer 1

Do you have reference to the precise definition of “distributed session” you have in mind?

I think your idea is that there’s a client (e.g a browser) and a server (eg. a servlet engine) and the Session state is distributed in the sense that the responsibility for the session is distributed between client and server – so for example the client must send a particular cookie with every request and the server must identify which session belongs to which client.

There are fundamental problems that need to be solved: consistency, reliability and scalability, by having session state you make one, or the other, or both difficult.

Simple case: The server persists the state to a database after every requests. Quite reliable, but expensive (DB write every time), Quite scalable, can have many copies of the server. Application developer must make sure the state can be persisted – that often means that Classes need to be Serializable. And if you put lots of stuff in the session it gets expensive!

So keep it memory: let’s not persist the session, keep it in memory. That performs better at the expense of reliability, now if we lose the server we lose the session. And we need to make sure that every request from a client goes to the same server instance, so scalability is tricky. We can’t simply offload requests to other server copies, they wont have the session.

So distribute the session: some app servers have clever distribution schemes to pass the session to other instances. Often this is thought to be cheaper than a DB, in practice it may not be. Once again the app developer needs to make the session serializable. Usually you still need good client/server affinity so you hit the same server most times, this results in less session copying.

Often what we really need to do is get selective. Not all of a session is important. We’d hate to lose a shopping cart, but the list of what we just looked at? Suppose that list was just a bit out of date would it matter.

Hence my general recommendation: Don’t use session state for things you really care about, don’t use session state as a general dumping ground. By and large developers are much better at putting things into a session than they are at tidying up again. Large (more than a k or two) persistent sessions are a severe problem.

So as a rule of thumb: persist important stuff to a db, consider putting some stuff in a cookie (effectively give responsibility to the client), put into the session only stuff that can be easily recreated. Then you can just rely on simple session affinity, and no persistence/distribution between server instances.