Jetty Logo
Version: 9.4.8.v20171121
Contact the core Jetty developers at www.webtide.com

private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services for sponsored feature development

Chapter 10. Session Management

Table of Contents

Session Architecture
Session Components
The SessionIdManager and the Housekeeper
The L1 Session Cache
Non-Persistent Sessions
Persistent Sessions: File System
Persistent Sessions: JDBC
Persistent Sessions: MongoDB
Persistent Sessions: Inifinspan
Persistent Sessions: Hazelcast
Persistent Sessions: Google Cloud DataStore
Persistent Sessions: The L2 Session Data Cache
Session Use Cases

Sessions are a concept within the Servlet api which allow requests to store and retrieve information across the time a user spends in an application. Choosing the correct session manager implementation is an important consideration for every application as each can fit and perform optimally in different situations. If you need a simple in-memory session manager that can persist to disk then session management using the local file system can be a good place to start. If you need a session manager that can work in a clustered scenario with multiple instances of Jetty, then the JDBC session manager can be an excellent option. Jetty also offers more niche session managers that leverage backends such as MongoDB, Inifinispan, or even Google’s Cloud Data Store.

Session Architecture

Changes in Session Architecture

The architecture of Session Management Jetty changed significantly in Jetty 9.4. These changes have resulted in Sessions not only being easier to configure but making them much more pluggable for various technologies.

In previous versions of Jetty, users were required to configure a separate SessionIdManager for each kind of session clustering technology being implemented (JDBC, MongoDB..etc.). In Jetty 9.4, there is now a single SessionIdManager implementation which works across all types of session clustering technologies. Likewise, prior to Jetty 9.4 there were several different instances of the SessionManager class. Instead of a single SessionManager though, it has been done away with entirely, with most of it’s functionality moved to the SesssionHandler class. Additionally, Jetty 9.4 introduced the concepts of a SessionCache and an associated SessionDataStore (both explained below).

Finally, Session scavenging has been re-worked. Where previously each SessionManager instance would periodically scan the in-memory (or clustered) sessions for expired sessions, there is now a single generic scavenger thread which instructs the SessionHandler to clean up expired sessions. Session expiration has been changed to use a much more efficient timer-based mechanism that avoids constant iteration over all current sessions in memory by the scavenger.

Session Architecture Hierarchy

Each Jetty instance has a singular SessionIdManager to handle all session requests, regardless of clustering technology. For each context on the server there is one (1) SessionCache which contains all of the Session objects for the given context. The benefit of the SessionCache is to ensure that simultaneous requests accessing the same Session Id in the same context always operate on the same Session object. The SessionCache implementation supplied with the Jetty distribution does just that: keeps Session objects in memory so that they can be shared between simultaneous requests. However, it is possible to provide your own implementation that never shares Session objects should you require it.

Where the SessionCache handles Session information, Session data is stored in a SessionDataStore that is specific to the clustering technology being implemented. There is only one (1) SessionDataStore per SessionCache.

Visually the session architecture can be represented like this:

SessionsHierarchy

Configuring Sessions in the Jetty Distribution

Configuring session management involves selecting a module for the desired type of session caching behavior, and a module for the type of session persistence.

Jetty provides two different session caches: the DefaultSessionCache which holds sessions in memory, and the NullSessionCache which does not. There is more information on both of these types of session caching and the circumstances which would lead you to select one or the other in the Session Components section, and more information on the configuration options of each in the L1 Session Cache section.

For session persistence, Jetty provides a number of different implementations from which to choose including non-persistence, local file storage, clustered technologies such as JDBC, MongoDB, Inifinispan, Google Cloud Datastore, and Hazelcast.

Depending on your persistence technology, to enhance performance, you may want to use an L2 cache for session data, in which case Jetty provides the memcached L2 session data cache.

See an error or something missing? Contribute to this documentation at Github!(Generated: 2017-11-21)