Version: 9.4.14.v20181114 |

Session Use Cases
Previous | Chapter 10. Session Management Home | Next

##### 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

## Session Use Cases

### Clustering with a Sticky Load Balancer

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.

### Clustering Without a Sticky Load Balancer

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.

### Handling corrupted or unloadable session data

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.

### Configuring Sessions via Jetty XML

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.

> ### Note

> If you explicitly configure the `SessionCache` and `SessionDataStore` for a `SessionHandler` in a context xml file or `jetty-web.xml` file, any session modules you already have enabled are ignored. So, for example, if you had enabled the `session-store-gcloud module` for your sever, you could force a particular webapp to use the `FileSessionDataStore` by explicitly configuring it in either a context xml file or a `jetty-web.xml` file as shown above.

Previous | Top | Next
Persistent Sessions: The L2 Session Data Cache | Home | Chapter 11. Jetty Logging

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