Preferably, your cluster will utilize a sticky load balancer. This will route requests for the same Session to the same Jetty instance. In this case, the DefaultSessionCache can be used to keep in-use Session objects in memory. You can fine-tune the cache by controlling how long Session objects remain in memory with the eviction policy settings.

If you have a large number of Sessions or very large Session objects, then you may want to manage your memory allocation by controlling the amount of time Session objects spend in the cache. The EVICT_ON_SESSION_EXIT eviction policy will remove a Session object from the cache as soon as the last simultaneous request referencing it exits. Alternatively, the EVICT_ON_INACTIVITY policy will remove a Session object from the cache after a configurable amount of time has passed without a request referencing it.

If your Sessions are very long lived and infrequently referenced, you might use the EVICT_ON_INACTIVITY_POLICY to control the size of the cache.

If your Sessions are small, or relatively few or stable in number or they are read-mostly, then you might select the NEVER_EVICT policy. With this policy, Session objects will remain in the cache until they either expire or are explicitly invalidated.

If you have a high likelihood of simultaneous requests for the same session object, then the EVICT_ON_SESSION_EXIT policy will ensure the Session object stays in the cache as long as it is needed.

Without a sticky load balancer requests for the same session may arrive on any node in the cluster. This means it is likely that the copy of the Session object in any SessionCache is likely to be out-of-date, as the Session was probably last accessed on a different node. In this case, your choices are to use either the NullSessionCache or to de-tune the DefaultSessionCache. If you use the NullSessionCache all Session object caching is avoided. This means that every time a request references a session it must be brought in from persistent storage. It also means that there can be no sharing of Session objects for multiple requests for the same session: each will have their own Session object. Furthermore, the outcome of session writes are indeterminate because the Servlet Specification does not mandate ACID transactions for sessions.

If you use the DefaultSessionCache, there is a risk that the caches on some nodes will contain out-of-date Session information as simultaneous requests for the same session are scattered over the cluster. To mitigate this somewhat you can use the EVICT_ON_SESSION_EXIT eviction policy: this will ensure that the Session is removed from the cache as soon as the last simultaneous request for it exits. Again, due to the lack of Session transactionality, the ordering outcome of write operations cannot be guaranteed. As the Session is cached while at least one request is accessing it, it is possible for multiple simultaneous requests to share the same Session object.

For various reasons it might not be possible for the SessionDataStore to re-read a stored session. One scenario is that the session stores a serialized object in it’s attributes, and after a redeployment there in an incompatible class change. Using the setter SessionCache.setRemoveUnloadableSessions(true) will allow the SessionDataStore to delete the unreadable session from persistent storage. This can be useful from preventing the scavenger from continually generating errors on the same expired, but un-restorable, session.

With the provided session modules, there is no need to configure a context xml or jetty-web.xml file for sessions. That said, if a user wishes to configure sessions this way, it is possible using Jetty IoC XML format.

Below is an example of how you could configure a the FileSessionDataStore, but the same concept would apply to any of the *SessionDataStores discussed in this chapter:

<Configure class="org.eclipse.jetty.webapp.WebAppContext">
  <Call id="sh" name="getSessionHandler">
    <Set name="sessionCache">
      <New class="org.eclipse.jetty.server.session.DefaultSessionCache">
        <Arg><Ref id="sh"/></Arg>
        <Set name="sessionDataStore">
           <New class="org.eclipse.jetty.server.session.FileSessionDataStore">
             <Set name="storeDir">/tmp/sessions</Set>
           </New>
        </Set>
      </New>
    </Set>
  </Call>
</Configure>

The example above functions in either a jetty-web.xml file or a context xml descriptor file.