With ColdFusion Enterprise, creating clusters and replicating session variables should be as simple as doing this via the ColdFusion Administrator GUI.  However I have found this to be unpredictable at times so this blog posting is a lead-in to what actually is going on, "under-the-covers".

One of the most sought after features in clustering is finding the best way for a users session information to be replicated across a cluster.  Or more succinctly, finding a way to make sure a users session information is preserved if they get moved around from instance to instance, which in pre ColdFusion MX, pre Java days was both limited and resource intensive.

Before getting into the main discussion of this blog piece, I thought it might be useful to discuss what is actually going on relating to maintaining session state and session replication, in the Java world.   ColdFusion MX forward embraced the Java Servlet world, in fact JRun, which ColdFusion runs in by default, is a Java Servlet container which is fully J2EE-Java EE certified.  In applications running in a J2EE-Java EE environment there are four distinct ways of storing user session information.

• In the Data Tier - In the ColdFusion world we use the client scope for this.
• In cookies on the users browser.
• In the Enterprise Tier - with Enterprise JavaBeans (EJB) using stateful session beans.
• In the Web tier using the HttpSession interface from the Servlet API

In this article we will focus on the the last item in our list above; using HttpSession from the Servlet API. When using HttpSession, the session is tied to a specific user, but shared across all servlets in a Web application.  It would be theoretically possible to have a complete copy of all session information at all times on all instances in a cluster and simply then use a "round-robin" algorithm so that every user request took them to a different instance.  My experience is that this is unnecessary and very costly in terms of messaging and networking.  I always advocate the use of round-robin with sticky sessions.  In this case the user is sent to a particular instance and remains there unless that instance fails.

The next thing to consider is what type of data can or should be stored, via the HttpSession Servlet API.  We touched on client variables earlier in this article.  The advantage of the client variable scope is that it is stored in a database which can be accessed from any instance in a cluster, the disadvantage is that complex data types cannot be stored directly in the client scope without serialization and de-serialization.  In addition, there will be more hits against a database during a users session.  We are definitely able to store complex data types at the session level.

As a users session information is stored in memory on a particular instance this data is lost if a user is moved to another instance.  The first level and simplest way of dealing with this is by using what are called "sticky sessions".  When sticky sessions are used a user sticks to the instance they first go to, therefore their session information is always available whilst they remain on that instance, as it is in memory on that instance.  With sticky sessions enabled (aka session affinity), users are only moved to a different instance if the instance they are on fails.  So then, what can we do about users session information in that case?  Enter Java J2EE-Java EE session replication, sometimes also known as the "buddy" system.  I have worked with several clients who have tried to use this in ColdFusion applications.  They requested my help because they found getting "buddy" replication up and running to be complex and also sometimes unpredictable in ongoing operation.  I was interested to read this comment in a library article on the IBM web site. "Some application servers support memory-based replication to "buddy" nodes, where each session exists on one primary server and one (or more) backup server. Such schemes scale better than replicating all sessions to all servers, but complicate the job of the load balancer when it needs to fail the session over to another server because it has to figure out which other server(s) has that session."  In my experience, there has not been a way to specifically notify a clustering device about the location of replicated session information in a ColdFusion - JRun peer-to-peer cluster.

In ColdFusion clustering we are in fact using the J2EE Servlet Container (typically JRun) and for those wanting more detailed information about how JRun uses httpSession, there is some good information.

As a general tip, you will find much more information about all things clustering in the JRun documentation than in the ColdFusion documentation.