The amazing adventures of Doug Hughes

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.

Comments on: "HA – Clustering – Replicating Session Scope" (11)

  1. Mike Brunt said:

    Just a quick comment from me, I refer to a link to some expanded JRun information on httpSession here is that site…

    Apologies that this is not in the main body.


  2. Steven Wood said:

    Thanks for the continued clustering articles. We are currently running vertical clustering (CF8 Enterprise multi-server) with some of our clients who demand high availability. So far, we have had success with this.

    We are currently investigating horizontal clustering across multiple machines in order to better manage our own scalability. Session replication across the servers will be critical to making it all work.


  3. Damon Gentry said:

    When using JRun session replication, you’ll want to limit the number of replication buddies. The last recommendation I saw was to limit each replication group to no more than 4 buddies. The reason for this is that each member of the group is sharing its session data with the other members. (Server ‘A’ is keeping track of its user’s session data in memory, along with a copy of the session data for Servers ‘B’, ‘C’, and ‘D’.) In addition to the increased memory footprint, there is also increased network traffic between all nodes of the server group because each change to a user’s session must be communicated to all of the other buddies.

    If your application doesn’t store a lot of data in the session scope, and you have fast network interfaces on all your servers, you can probably use more than 4 replication buddies. However, if you are limited on memory and store lots of data in the session scope, I’d consider limiting replication buddies to somewhere between 2 and 4.

    WebLogic uses a slightly different approach that is more efficient (in terms of memory usage) but is also more difficult to setup (in terms of working with your load balancer). When one node of a WebLogic cluster receives a brand new ‘session client’, it does the following:

    1. Creates the session data in memory
    2. Randomly picks another node in the cluster and asks for help. If the response is no, then it asks another node for help (and so on until it gets a yes). When a node responds with a yes, then the two node agree to perform a 1-way synchronization of session data (primary to backup).
    3. Creates a cookie that instructs the client that contains the node IDs for the primary and the backup node member.
    4. Subsequent requests to the LB send this data back so that the LB knows where to route the request (preferred node, backup node if preferred is not available).
    5. If the backup node gets a request from that client, it becomes the primary, asks for a new backup node, and updates the client cookie to reflect the change.

    There are 2 downsides with this approach: 1) Your load balancer has to know how to use the cookie to route requests so that session affinity is observed, and 2) If both nodes (primary and backup) are gone, then the session data is lost.


  4. Mike Brunt said:

    @Steven I am sorry I did not acknowledge your posting before, thanks for the information. Did you ever go further with horizontal clustering?


  5. Mike Brunt said:

    @Damon thank you very much for your insights here and the number you found to be a good one for maximum buddies in a single cluster.

    Also, thanks for your information re WebLogic.

    There are not many out there who have worked with J2EE clustering at any length do you mind sharing with us your background on that? Also, do you have any thoughts regarding web server clustering?


  6. Damon Gentry said:


    I’ve never really considered the topic of ‘web server clustering’. I typically will load balance the HTTP servers via hardware, software, or if other solutions aren’t available, round-robin DNS.

    BTW: My preferred load balancer is the Citrix NetScaler.

    I typically store my web content (doc root) on a shared file system (NFS, SAN, NAS, etc.) that is configured to be highly available. However, I tend to store my web server configuration files (httpd.conf, mime,types, etc.) on each local HTTP server.

    I also take advantage of session affinity (stickiness) when possible to ensure that clients stay on one particular server during their visit, and I use the load balancer to equalize the number of clients connected to each HTTP server in the server farm.

    Finally, I use JRun Clustering (In-Memory Session Replication) to ensure that I can do rolling maintenance without disrupting client sessions.

    This general setup has worked well for me regardless of OS platform (Solaris, Linux, Windows) or HTTP Server (Apache, IIS, SunOne).


  7. wow power leveling said:

    world of warcraft power leveling[url=]world of warcraft power leveling[/url],[url=]world of warcraft power leveling[/url],[url=]wow power leveling[/url],[url=]wow power leveling [/url],[url=]cheap wow power leveling[/url],[url=]cheap wow power leveling[/url],[url=]wow powerleveling[/url],[url=]wow powerleveling[/url] world of warcraft power leveling,wow power leveling,cheap wow power leveling

    buy [url=]world of warcraft power leveling[/url],[url=]world of warcraft power leveling[/url],[url=]wow power leveling[/url],[url=]wow power leveling [/url],[url=]cheap wow power leveling[/url],[url=]cheap wow power leveling[/url],[url=]wow powerleveling[/url],[url=]wow powerleveling[/url] for cheap !


  8. Hello,

    as we all know, it’s important to let everybody know that we have nice homepage.
    So, this is mine 🙂



Comments are closed.

Tag Cloud

%d bloggers like this: