documentation/9.4.x/sessions-usecases.html - www.eclipse.org/jetty - Git at Google

 <html><head>
       <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
    <title>Session Use Cases</title><link rel="stylesheet" type="text/css" href="css/docbook.css"><meta name="generator" content="DocBook XSL Stylesheets V1.79.1"><meta name="keywords" content="jetty, servlet, servlet-api, cometd, http, websocket, eclipse, maven, java, server, software"><link rel="home" href="index.html" title="Jetty"><link rel="up" href="session-management.html" title="Chapter&nbsp;10.&nbsp;Session Management"><link rel="prev" href="session-configuration-memcachedsessiondatastore.html" title="Persistent Sessions: The L2 Session Data Cache"><link rel="next" href="configuring-logging.html" title="Chapter&nbsp;11.&nbsp;Jetty Logging"><link xmlns:jfetch="java:org.eclipse.jetty.xslt.tools.JavaSourceFetchExtension" xmlns:fetch="java:org.eclipse.jetty.xslt.tools.SourceFetchExtension" xmlns:d="http://docbook.org/ns/docbook" xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0" xmlns:xslthl="http://xslthl.sf.net" xmlns:gcse="http://www.google.com" xmlns:date="http://exslt.org/dates-and-times" rel="shortcut icon" href="images/favicon.ico"><link rel="stylesheet" href="css/highlighter/foundation.css"><script src="js/highlight.pack.js"></script><script>
       hljs.initHighlightingOnLoad();
     </script><link type="text/css" rel="stylesheet" href="css/font-awesome/font-awesome.min.css"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><table xmlns:jfetch="java:org.eclipse.jetty.xslt.tools.JavaSourceFetchExtension" xmlns:fetch="java:org.eclipse.jetty.xslt.tools.SourceFetchExtension" xmlns:d="http://docbook.org/ns/docbook" xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0" xmlns:xslthl="http://xslthl.sf.net" xmlns:gcse="http://www.google.com" xmlns:date="http://exslt.org/dates-and-times"><tr><td style="width: 25%"><a href="http://www.eclipse.org/jetty"><img src="images/jetty-header-logo.png" alt="Jetty Logo"></a><br><span style="font-size: small">
             Version: 9.4.28-SNAPSHOT</span></td><td style="width: 50%"></td></tr></table><div xmlns:jfetch="java:org.eclipse.jetty.xslt.tools.JavaSourceFetchExtension" xmlns:fetch="java:org.eclipse.jetty.xslt.tools.SourceFetchExtension" xmlns:d="http://docbook.org/ns/docbook" xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0" xmlns:xslthl="http://xslthl.sf.net" xmlns:gcse="http://www.google.com" xmlns:date="http://exslt.org/dates-and-times" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Session Use Cases</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="session-configuration-memcachedsessiondatastore.html"><i class="fa fa-chevron-left" aria-hidden="true"></i> Previous</a>&nbsp;</td><th width="60%" align="center">Chapter&nbsp;10.&nbsp;Session Management<br><a accesskey="p" href="index.html"><i class="fa fa-home" aria-hidden="true"></i> Home</a></th><td width="20%" align="right">&nbsp;<a accesskey="n" href="configuring-logging.html">Next <i class="fa fa-chevron-right" aria-hidden="true"></i></a></td></tr></table><hr></div><div xmlns:jfetch="java:org.eclipse.jetty.xslt.tools.JavaSourceFetchExtension" xmlns:fetch="java:org.eclipse.jetty.xslt.tools.SourceFetchExtension" xmlns:d="http://docbook.org/ns/docbook" xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0" xmlns:xslthl="http://xslthl.sf.net" xmlns:gcse="http://www.google.com" xmlns:date="http://exslt.org/dates-and-times" class="jetty-callout"><h5 class="callout"><a href="http://www.webtide.com/">Contact the core Jetty developers at
           <span class="website">www.webtide.com</span></a></h5><p>
  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
       </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sessions-usecases"></a>Session Use Cases</h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="section"><a href="sessions-usecases.html#_clustering_with_a_sticky_load_balancer">Clustering with a Sticky Load Balancer</a></span></dt><dt><span class="section"><a href="sessions-usecases.html#_clustering_without_a_sticky_load_balancer">Clustering Without a Sticky Load Balancer</a></span></dt><dt><span class="section"><a href="sessions-usecases.html#_handling_corrupted_or_unloadable_session_data">Handling corrupted or unloadable session data</a></span></dt><dt><span class="section"><a href="sessions-usecases.html#_configuring_sessions_via_jetty_xml">Configuring Sessions via Jetty XML</a></span></dt></dl></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="_clustering_with_a_sticky_load_balancer"></a>Clustering with a Sticky Load Balancer</h3></div></div></div><p>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 <code class="literal">DefaultSessionCache</code> 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.</p><p>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 <code class="literal">EVICT_ON_SESSION_EXIT</code> eviction policy will remove a Session object from the cache as soon as the last simultaneous request referencing it exits.
 Alternatively, the <code class="literal">EVICT_ON_INACTIVITY</code> policy will remove a Session object from the cache after a configurable amount of time has passed without a request referencing it.</p><p>If your Sessions are very long lived and infrequently referenced, you might use the <code class="literal">EVICT_ON_INACTIVITY_POLICY</code> to control the size of the cache.</p><p>If your Sessions are small, or relatively few or stable in number or they are read-mostly, then you might select the <code class="literal">NEVER_EVICT</code> policy.
 With this policy, Session objects will remain in the cache until they either expire or are explicitly invalidated.</p><p>If you have a high likelihood of simultaneous requests for the same session object, then the <code class="literal">EVICT_ON_SESSION_EXIT</code> policy will ensure the Session object stays in the cache as long as it is needed.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="_clustering_without_a_sticky_load_balancer"></a>Clustering Without a Sticky Load Balancer</h3></div></div></div><p>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 <code class="literal">SessionCache</code> is likely to be out-of-date, as the Session was probably last accessed on a different node.
 In this case, your <code class="literal">choices</code> are to use either the <code class="literal">NullSessionCache</code> or to de-tune the <code class="literal">DefaultSessionCache</code>.
 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.</p><p>If you use the <code class="literal">DefaultSessionCache</code>, 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 <code class="literal">EVICT_ON_SESSION_EXIT</code> 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.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="_handling_corrupted_or_unloadable_session_data"></a>Handling corrupted or unloadable session data</h3></div></div></div><p>For various reasons it might not be possible for the <code class="literal">SessionDataStore</code> to re-read a stored session.
 One scenario is that the session stores a serialized object in it&#8217;s attributes, and after a redeployment there in an incompatible class change.
 Using the setter <code class="literal">SessionCache.setRemoveUnloadableSessions(true)</code> will allow the <code class="literal">SessionDataStore</code> 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.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="_configuring_sessions_via_jetty_xml"></a>Configuring Sessions via Jetty XML</h3></div></div></div><p>With the provided session modules, there is no need to configure a context xml or <code class="literal">jetty-web.xml</code> file for sessions.
 That said, if a user wishes to configure sessions this way, it is possible using <a class="link" href="reference-section.html#jetty-xml-syntax" title="Jetty XML Syntax">Jetty IoC XML format.</a></p><p>Below is an example of how you could configure a the <a class="link" href="configuring-sessions-file-system.html" title="Persistent Sessions: File System"><code class="literal">FileSessionDataStore</code></a>, but the same concept would apply to any of the *SessionDataStores discussed in this chapter:</p><pre xmlns:jfetch="java:org.eclipse.jetty.xslt.tools.JavaSourceFetchExtension" xmlns:fetch="java:org.eclipse.jetty.xslt.tools.SourceFetchExtension" xmlns:d="http://docbook.org/ns/docbook" xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0" xmlns:xslthl="http://xslthl.sf.net" xmlns:gcse="http://www.google.com" xmlns:date="http://exslt.org/dates-and-times"><code>&lt;Configure class="org.eclipse.jetty.webapp.WebAppContext"&gt;
   &lt;Call id="sh" name="getSessionHandler"&gt;
     &lt;Set name="sessionCache"&gt;
       &lt;New class="org.eclipse.jetty.server.session.DefaultSessionCache"&gt;
         &lt;Arg&gt;&lt;Ref id="sh"/&gt;&lt;/Arg&gt;
         &lt;Set name="sessionDataStore"&gt;
            &lt;New class="org.eclipse.jetty.server.session.FileSessionDataStore"&gt;
              &lt;Set name="storeDir"&gt;/tmp/sessions&lt;/Set&gt;
            &lt;/New&gt;
         &lt;/Set&gt;
       &lt;/New&gt;
     &lt;/Set&gt;
   &lt;/Call&gt;
 &lt;/Configure&gt;</code></pre><p>The example above functions in either a <code class="literal">jetty-web.xml</code> file or a <a class="link" href="configuring-specific-webapp-deployment.html#using-basic-descriptor-files" title="Using Basic Descriptor Files">context xml descriptor file.</a></p><div class="blockquote"><blockquote class="blockquote"><div xmlns:jfetch="java:org.eclipse.jetty.xslt.tools.JavaSourceFetchExtension" xmlns:fetch="java:org.eclipse.jetty.xslt.tools.SourceFetchExtension" xmlns:d="http://docbook.org/ns/docbook" xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0" xmlns:xslthl="http://xslthl.sf.net" xmlns:gcse="http://www.google.com" xmlns:date="http://exslt.org/dates-and-times" class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title"><i class="fa fa-asterisk" aria-hidden="true"></i> Note</h3><p>If you explicitly configure the <code class="literal">SessionCache</code> and <code class="literal">SessionDataStore</code> for a <code class="literal">SessionHandler</code> in a context xml file or <code class="literal">jetty-web.xml</code> file, any session modules you already have enabled are ignored.
 So, for example, if you had enabled the <code class="literal">session-store-gcloud module</code> for your sever, you could force a particular webapp to use the <code class="literal">FileSessionDataStore</code> by explicitly configuring it in either a context xml file or a <code class="literal">jetty-web.xml</code> file as shown above.</p></div></blockquote></div></div></div><script type="text/javascript">
       SyntaxHighlighter.all()
     </script><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="session-configuration-memcachedsessiondatastore.html"><i class="fa fa-chevron-left" aria-hidden="true"></i> Previous</a>&nbsp;</td><td width="20%" align="center"><a accesskey="u" href="session-management.html"><i class="fa fa-chevron-up" aria-hidden="true"></i> Top</a></td><td width="40%" align="right">&nbsp;<a accesskey="n" href="configuring-logging.html">Next <i class="fa fa-chevron-right" aria-hidden="true"></i></a></td></tr><tr><td width="40%" align="left" valign="top">Persistent Sessions: The L2 Session Data Cache&nbsp;</td><td width="20%" align="center"><a accesskey="h" href="index.html"><i class="fa fa-home" aria-hidden="true"></i> Home</a></td><td width="40%" align="right" valign="top">&nbsp;Chapter&nbsp;11.&nbsp;Jetty Logging</td></tr></table></div><p xmlns:jfetch="java:org.eclipse.jetty.xslt.tools.JavaSourceFetchExtension" xmlns:fetch="java:org.eclipse.jetty.xslt.tools.SourceFetchExtension" xmlns:d="http://docbook.org/ns/docbook" xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0" xmlns:xslthl="http://xslthl.sf.net" xmlns:gcse="http://www.google.com" xmlns:date="http://exslt.org/dates-and-times"><div class="jetty-callout">
             See an error or something missing?
             <span class="callout"><a href="http://github.com/eclipse/jetty.project">Contribute to this documentation at
                 <span class="website"><i class="fa fa-github" aria-hidden="true"></i> Github!</span></a></span><span style="float: right"><i>(Generated: 2020-03-10)</i></span></div></p></body></html>
	<html><head>
	<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
	<title>Session Use Cases</title><link rel="stylesheet" type="text/css" href="css/docbook.css"><meta name="generator" content="DocBook XSL Stylesheets V1.79.1"><meta name="keywords" content="jetty, servlet, servlet-api, cometd, http, websocket, eclipse, maven, java, server, software"><link rel="home" href="index.html" title="Jetty"><link rel="up" href="session-management.html" title="Chapter 10. Session Management"><link rel="prev" href="session-configuration-memcachedsessiondatastore.html" title="Persistent Sessions: The L2 Session Data Cache"><link rel="next" href="configuring-logging.html" title="Chapter 11. Jetty Logging"><link xmlns:jfetch="java:org.eclipse.jetty.xslt.tools.JavaSourceFetchExtension" xmlns:fetch="java:org.eclipse.jetty.xslt.tools.SourceFetchExtension" xmlns:d="http://docbook.org/ns/docbook" xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0" xmlns:xslthl="http://xslthl.sf.net" xmlns:gcse="http://www.google.com" xmlns:date="http://exslt.org/dates-and-times" rel="shortcut icon" href="images/favicon.ico"><link rel="stylesheet" href="css/highlighter/foundation.css"><script src="js/highlight.pack.js"></script><script>
	hljs.initHighlightingOnLoad();
	</script><link type="text/css" rel="stylesheet" href="css/font-awesome/font-awesome.min.css"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><table xmlns:jfetch="java:org.eclipse.jetty.xslt.tools.JavaSourceFetchExtension" xmlns:fetch="java:org.eclipse.jetty.xslt.tools.SourceFetchExtension" xmlns:d="http://docbook.org/ns/docbook" xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0" xmlns:xslthl="http://xslthl.sf.net" xmlns:gcse="http://www.google.com" xmlns:date="http://exslt.org/dates-and-times"><tr><td style="width: 25%"><a href="http://www.eclipse.org/jetty"><img src="images/jetty-header-logo.png" alt="Jetty Logo"></a><br><span style="font-size: small">
	Version: 9.4.28-SNAPSHOT</span></td><td style="width: 50%"></td></tr></table><div xmlns:jfetch="java:org.eclipse.jetty.xslt.tools.JavaSourceFetchExtension" xmlns:fetch="java:org.eclipse.jetty.xslt.tools.SourceFetchExtension" xmlns:d="http://docbook.org/ns/docbook" xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0" xmlns:xslthl="http://xslthl.sf.net" xmlns:gcse="http://www.google.com" xmlns:date="http://exslt.org/dates-and-times" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Session Use Cases</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="session-configuration-memcachedsessiondatastore.html"><i class="fa fa-chevron-left" aria-hidden="true"></i> Previous</a> </td><th width="60%" align="center">Chapter 10. Session Management<br><a accesskey="p" href="index.html"><i class="fa fa-home" aria-hidden="true"></i> Home</a></th><td width="20%" align="right"> <a accesskey="n" href="configuring-logging.html">Next <i class="fa fa-chevron-right" aria-hidden="true"></i></a></td></tr></table><hr></div><div xmlns:jfetch="java:org.eclipse.jetty.xslt.tools.JavaSourceFetchExtension" xmlns:fetch="java:org.eclipse.jetty.xslt.tools.SourceFetchExtension" xmlns:d="http://docbook.org/ns/docbook" xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0" xmlns:xslthl="http://xslthl.sf.net" xmlns:gcse="http://www.google.com" xmlns:date="http://exslt.org/dates-and-times" class="jetty-callout"><h5 class="callout"><a href="http://www.webtide.com/">Contact the core Jetty developers at
	<span class="website">www.webtide.com</span></a></h5><p>
	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
	</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sessions-usecases"></a>Session Use Cases</h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="section"><a href="sessions-usecases.html#_clustering_with_a_sticky_load_balancer">Clustering with a Sticky Load Balancer</a></span></dt><dt><span class="section"><a href="sessions-usecases.html#_clustering_without_a_sticky_load_balancer">Clustering Without a Sticky Load Balancer</a></span></dt><dt><span class="section"><a href="sessions-usecases.html#_handling_corrupted_or_unloadable_session_data">Handling corrupted or unloadable session data</a></span></dt><dt><span class="section"><a href="sessions-usecases.html#_configuring_sessions_via_jetty_xml">Configuring Sessions via Jetty XML</a></span></dt></dl></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="_clustering_with_a_sticky_load_balancer"></a>Clustering with a Sticky Load Balancer</h3></div></div></div><p>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 <code class="literal">DefaultSessionCache</code> 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.</p><p>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 <code class="literal">EVICT_ON_SESSION_EXIT</code> eviction policy will remove a Session object from the cache as soon as the last simultaneous request referencing it exits.
	Alternatively, the <code class="literal">EVICT_ON_INACTIVITY</code> policy will remove a Session object from the cache after a configurable amount of time has passed without a request referencing it.</p><p>If your Sessions are very long lived and infrequently referenced, you might use the <code class="literal">EVICT_ON_INACTIVITY_POLICY</code> to control the size of the cache.</p><p>If your Sessions are small, or relatively few or stable in number or they are read-mostly, then you might select the <code class="literal">NEVER_EVICT</code> policy.
	With this policy, Session objects will remain in the cache until they either expire or are explicitly invalidated.</p><p>If you have a high likelihood of simultaneous requests for the same session object, then the <code class="literal">EVICT_ON_SESSION_EXIT</code> policy will ensure the Session object stays in the cache as long as it is needed.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="_clustering_without_a_sticky_load_balancer"></a>Clustering Without a Sticky Load Balancer</h3></div></div></div><p>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 <code class="literal">SessionCache</code> is likely to be out-of-date, as the Session was probably last accessed on a different node.
	In this case, your <code class="literal">choices</code> are to use either the <code class="literal">NullSessionCache</code> or to de-tune the <code class="literal">DefaultSessionCache</code>.
	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.</p><p>If you use the <code class="literal">DefaultSessionCache</code>, 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 <code class="literal">EVICT_ON_SESSION_EXIT</code> 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.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="_handling_corrupted_or_unloadable_session_data"></a>Handling corrupted or unloadable session data</h3></div></div></div><p>For various reasons it might not be possible for the <code class="literal">SessionDataStore</code> 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 <code class="literal">SessionCache.setRemoveUnloadableSessions(true)</code> will allow the <code class="literal">SessionDataStore</code> 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.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="_configuring_sessions_via_jetty_xml"></a>Configuring Sessions via Jetty XML</h3></div></div></div><p>With the provided session modules, there is no need to configure a context xml or <code class="literal">jetty-web.xml</code> file for sessions.
	That said, if a user wishes to configure sessions this way, it is possible using <a class="link" href="reference-section.html#jetty-xml-syntax" title="Jetty XML Syntax">Jetty IoC XML format.</a></p><p>Below is an example of how you could configure a the <a class="link" href="configuring-sessions-file-system.html" title="Persistent Sessions: File System"><code class="literal">FileSessionDataStore</code></a>, but the same concept would apply to any of the *SessionDataStores discussed in this chapter:</p><pre xmlns:jfetch="java:org.eclipse.jetty.xslt.tools.JavaSourceFetchExtension" xmlns:fetch="java:org.eclipse.jetty.xslt.tools.SourceFetchExtension" xmlns:d="http://docbook.org/ns/docbook" xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0" xmlns:xslthl="http://xslthl.sf.net" xmlns:gcse="http://www.google.com" xmlns:date="http://exslt.org/dates-and-times"><code><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></code></pre><p>The example above functions in either a <code class="literal">jetty-web.xml</code> file or a <a class="link" href="configuring-specific-webapp-deployment.html#using-basic-descriptor-files" title="Using Basic Descriptor Files">context xml descriptor file.</a></p><div class="blockquote"><blockquote class="blockquote"><div xmlns:jfetch="java:org.eclipse.jetty.xslt.tools.JavaSourceFetchExtension" xmlns:fetch="java:org.eclipse.jetty.xslt.tools.SourceFetchExtension" xmlns:d="http://docbook.org/ns/docbook" xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0" xmlns:xslthl="http://xslthl.sf.net" xmlns:gcse="http://www.google.com" xmlns:date="http://exslt.org/dates-and-times" class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title"><i class="fa fa-asterisk" aria-hidden="true"></i> Note</h3><p>If you explicitly configure the <code class="literal">SessionCache</code> and <code class="literal">SessionDataStore</code> for a <code class="literal">SessionHandler</code> in a context xml file or <code class="literal">jetty-web.xml</code> file, any session modules you already have enabled are ignored.
	So, for example, if you had enabled the <code class="literal">session-store-gcloud module</code> for your sever, you could force a particular webapp to use the <code class="literal">FileSessionDataStore</code> by explicitly configuring it in either a context xml file or a <code class="literal">jetty-web.xml</code> file as shown above.</p></div></blockquote></div></div></div><script type="text/javascript">
	SyntaxHighlighter.all()
	</script><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="session-configuration-memcachedsessiondatastore.html"><i class="fa fa-chevron-left" aria-hidden="true"></i> Previous</a> </td><td width="20%" align="center"><a accesskey="u" href="session-management.html"><i class="fa fa-chevron-up" aria-hidden="true"></i> Top</a></td><td width="40%" align="right"> <a accesskey="n" href="configuring-logging.html">Next <i class="fa fa-chevron-right" aria-hidden="true"></i></a></td></tr><tr><td width="40%" align="left" valign="top">Persistent Sessions: The L2 Session Data Cache </td><td width="20%" align="center"><a accesskey="h" href="index.html"><i class="fa fa-home" aria-hidden="true"></i> Home</a></td><td width="40%" align="right" valign="top"> Chapter 11. Jetty Logging</td></tr></table></div><p xmlns:jfetch="java:org.eclipse.jetty.xslt.tools.JavaSourceFetchExtension" xmlns:fetch="java:org.eclipse.jetty.xslt.tools.SourceFetchExtension" xmlns:d="http://docbook.org/ns/docbook" xmlns:l="http://docbook.sourceforge.net/xmlns/l10n/1.0" xmlns:xslthl="http://xslthl.sf.net" xmlns:gcse="http://www.google.com" xmlns:date="http://exslt.org/dates-and-times"><div class="jetty-callout">
	See an error or something missing?
	<span class="callout"><a href="http://github.com/eclipse/jetty.project">Contribute to this documentation at
	<span class="website"><i class="fa fa-github" aria-hidden="true"></i> Github!</span></a></span><span style="float: right"><i>(Generated: 2020-03-10)</i></span></div></p></body></html>