Techniques for replicating session data include distributing: to all nodes in a cluster; to a subset of the nodes in the cluster; to a database; to a cluster server; etc. etc. To this range of solutions, cometd/bayeux now adds the possibility of using the client machine to store replicated session.
While it sounds strange, if you think about it, the client machine is the perfect place to store a replicated copy of the server session data. It is a machine that is always in communication to the correct webserver, if the client machine crashes, the session is by definition over so you don’t need to timeout the replicated data. Clients machines scale with the number of users, so if you have more users then you have then more machines available to store replicated session.
To test this concept I have created the BayeuxSessionManager for Jetty. This session manager keeps a dirty bit on the session, and if at the end of a request the session has been modified, then the session is serialized (should be encrypted) and B64 encoded and sent to the client as a Bayeux message. The client saves the opaque blob of session data. If the client is directed to a new server (due to policy, maintenance, failure or happenstance), then the Bayeux protocol will see that the client ID is not know and a re-handshake will be invoked. The session extension includes any saved blobs of session data with the handshake request, so that as the Bayeux connection is established with the new server, the session is restored and is again available.
Now I don’t think this approach is ever going to be 100% and I certainly would not like to see any pacemakers using this to communicate with a medical database about how many volts to zap you with to save you from a heart attack. But then it may be good enough to deal with enough common failures that you will be able to rest easy and avoid the stress levels the could cause a heart attack in the first place!
At this stage, this is only a proof of concept and more details do need to be worked out, including:
- encryption of the session data blob so that clients cannot see inside server data structures.
- how to deal with page reloads: should the client use some client side persistence (or is it good enough to expect that page reloads are unlikely to coincide with server failures?)
- how to deal with requests that need sessions that arrive on the new server before the bayeux connection is established.
I think all of these are solvable and for applications that are clustered primarily for scalability and availability, this technique could provide a bit of fault tolerance without the need for complex server interconnections or repositories than can hold all sessions from all nodes.
What this technique needs now is a real use-case to help drive it towards a complete solutions. So if anybody is interested in this style of replication and has a project that can afford to experiment with a new and novel approach, please contact me and we can see where this leads.