Webserver session objects have existed since the beginning of web programming. Many developers see them as the most convenient way to store session information. While some of this information is temporary and should be deleted once the session expires, the rest should be saved in some sort of persistent storage for the user’s next visit.
In recent years, web development has become more and more challenging, session data size has increased greatly to support the data the user expects to view, for example their friends or favorite articles. In addition, sites need to support a higher number of open sessions while maintaining high availability of the data.
Default session management in Tomcat and other web servers is no longer enough, for a number of reasons:
- Session data is not replicated and is only effective with a sticky session load balancer
- Data may be lost if Tomcat crashes, meaning the user may need to restart the flow from the beginning
- There currently isn’t any good solution for data eviction with peak loads, web servers crash from “out of memory” exceptions
- Data is not balanced between multiple Tomcats, and consequently can’t scale
- There is no good monitoring and management solution for the session data to resolve bottlenecks and SLA issues
Tomcat has two out of the box advanced session storage options, file persistence and JDBC (usually DB). They mainly solve issues with session availability between different Tomcat instances and resilience in the event of Tomcat crashes. However, because of their nature they do not provide a full solution – the primary reasons being performance and scalability limitations. Remember, developers have started to use sessions to avoid using DBs, this is because DBs don’t scale and suffer from high latency, and the session is meant to serve as the web servers cache and provide quick access to data. Therefore, storing the session info in a database essentially defeats the purpose of using the session in the first place. File systems can provide some advantages, but in the same way that the JDBC connection is not scalable nor highly available, what will happen in the event of disk failure?
Storing the session in Gigaspaces XAP intends to solve all of the issues above without changing the way your website works at all. We use the Tomcat HttpSessionAttributeListener in order to store individual session keys that are added. This replaces the Tomcat session manager when the code needs to access session keys. In order to scale and maintain high availability, I utilize the GigaSpaces highly available partition cluster, this enables the support of increased amounts of sessions without having to make the sacrifice of low latency as a result, as each partition has a backup for high availability. The cluster runs remotely on the Tomcat web servers to provide the full flexibility of adding more Tomcats or partitions on a need basis. Adding Tomcats instances serves the purpose of providing more http requests with smaller amounts of sessions. More partitions are used on sites that need to store large amounts of data per session or those that want to be able to maintain the session without expiration for longer periods of time.
Tomcat with Gigaspaces
Now let’s take a look at how GigaSpaces solves each of our challenges:
The session data is now stored on the Gigaspaces cluster. It is now highly available and can be reached from every Tomcat, which frees us from relying on Tomcat to maintain the session data in its cache, and there is no concern that the data will be lost if a Tomcat crashes. Session data is available between different Tomcat instances, therefore a sticky load balancer is optional.
Session object eviction can be controlled by Gigaspaces, using lease or custom eviction code. We override Tomcat default session expirations, and avoid the need to set it up for all our Tomcat instances.
Session data is partitioned/shared over the Gigaspaces cluster. The system can increase the number of concurrent users without reducing its SLA just by increasing the amount of resources the cluster uses.
Gigaspaces cluster comes with advanced monitoring tools that enable IT people to monitor the state of the cluster and keep it healthy and responsive. By using Gigaspaces for your session storage you enjoy all these advantages and more.
A local cache can be used as a near cache solution for sites that have a sticky session load balancer and would like to have the option of performing repeatable reads on the same data without remote calls.
In addition to the obvious advantages, there are many added possibilities when implementing this type of configuration. One example is using event driven containers running in the partition, and listening to session attributes that have been added. Doing so enables developers to execute business logic based on data placed in the session, without placing more stress on the Tomcat, such as, persistent relevant session information that should be kept for future use.
Using GigaSpaces and Tomcat
To get GigaSpaces working with your web app you need to make the following changes:
Add these lines to the web.xml
Add these lines to the context.xml