LDSTechForumProjects

HttpSession Replication with Tomcat

This article describes when you may need replication for your project and how you can enable it for various environments.

When you might need replication

HttpSession Replication is used to make sure that when an application is deployed in a clustered environment (more than 1 Tomcat instance), each HttpSession cache in each Tomcat is in sync and contains the same information. This allows for application load balancing and failover on high traffic applications. If your application isn't clustered or you're not worried about graceful failover, you do not need replication in your application architecture.

Replication Strategies

There are several ways you can perform session replication with your application. Which strategy you choose depends on resources and other application needs as well as the environment your project will be deployed in. Listed below are the possible strategies to achieve session replication with the ICS Java Stack. The Stack Team recommends these strategies in order of preference as well as if you are starting a new project or clustering an existing app.

  • Disable Session use with the ICS Stack 3.4.2+ sessionless state filters (Best for new apps or existing apps that want to take the time to remove session use and regression test everything)
  • JDBC Persistence Storage for Sessions in Tomcat (Best for existing apps, this option is the least invasive)
  • Utilize the Tomcat 7 session SimpleTcpCluster
  • Utilize a SAN storage device for File session storage

Disable Session use with the ICS Stack 3.4.2+ sessionless state filters

This strategy is cloud foundry friendly

By disabling the HttpSession use in your application you no longer need to worry about replicating it. ICS Stack 3.4.2 release and later provides servlet filters that will enable this functionality. This means all application state will reside on your front end, your database or some other caching mechanism. See the Creating Stateless Apps article for more info.

JDBC Persistence Storage for Sessions in Tomcat

This strategy is cloud foundry friendly

If you need session replication in your application then this is the best choice. By changing the session storage from a local disk to a database, multiple Tomcat's can use the same datastore. This is essentially moving your HttpSession state to a DB. This provides much better performance for large session swap outs compared to disk or file based session persistence. See the Tomcat documentation [1] for more info on setting up JDBC persistence storage and creating a session storage table.

Utilize the Tomcat 7 session SimpleTcpCluster

This strategy CANNOT be used with cloud foundry deployed applications

This requires that session information is maintained in memory and Tomcat will sync the in memory session with other Tomcat's participating in the cluster. See the Tomcat documentation [2] for info on configuration.

Utilize a SAN storage device for File session storage

This strategy CANNOT be used with cloud foundry deployed applications

This is probably the least preferred way to replicate a session but is an option if the other strategies don't work. Setup a common networked file system that you will write your session info to. Then configure all of your tomcats to use that same session file system. See the Tomcat docs [3] for configuration information.

This page was last modified on 9 December 2013, at 18:16.

Note: Content found in this wiki may not always reflect official Church information. See Terms of Use.