1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Session Configuration and 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-management.html" title="Chapter 10. Session Management"><link rel="next" href="configuring-sessions-memory.html" title="Non-Clustered Session Management: Memory"><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.1-SNAPSHOT</span></td><td style="width: 50%"><script type="text/javascript"> (function() {
var cx = '016459005284625897022:obd4lsai2ds';
var gcse = document.createElement('script');
gcse.type = 'text/javascript';
gcse.async = true;
gcse.src = (document.location.protocol == 'https:' ? 'https:' : 'http:') +
'//www.google.com/cse/cse.js?cx=' + cx;
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(gcse, s);
})();
</script><gcse:search></gcse:search></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 Configuration and Use Cases</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="session-management.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-sessions-memory.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-details"></a>Session Configuration and Use Cases</h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="section"><a href="sessions-details.html#_configuration_2">Configuration</a></span></dt><dt><span class="section"><a href="sessions-details.html#_use_cases">Use Cases</a></span></dt></dl></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="_configuration_2"></a>Configuration</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="_sessionidmanager"></a>SessionIdManager</h4></div></div></div><p>There is a maximum of 1 <code class="literal">SessionIdManager</code> per jetty Server instance.
Its purpose is to generate fresh, unique session ids and to coordinate the re-use of session ids amongst co-operating contexts.</p><p>Unlike in previous versions of Jetty, the <code class="literal">SessionIdManager</code> is agnostic with respect to the type of clustering technology chosen.</p><p>Jetty provides a default implementation - the <code class="literal">DefaultSessionIdManager</code> - which should meet the needs of most users.
If you do not explicitly enable one of the session modules, or otherwise configure a <code class="literal">SessionIdManager</code>, the <code class="literal">DefaultSessionIdManager</code> will be used.</p><p>If the <code class="literal">DefaultSessionIdManager</code> does not meet your needs, you can extend the <code class="literal">org.eclipse.jetty.server.session.AbstractSessionIdManager</code> or do a fresh implementation of the <code class="literal">org.eclipse.jetty.server.session.SessionIdManager</code> interface.</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="_housekeeper"></a>HouseKeeper</h4></div></div></div><p>There is a maximum of 1 <code class="literal">HouseKeeper</code> per <code class="literal">SessionIdManager</code>.
Its purpose is to periodically poll the <code class="literal">SessionHandlers</code> to clean out expired sessions.</p><p>By default the <code class="literal">HouseKeeper</code> will poll the <code class="literal">SessionHandlers</code> every 10 mins to find and delete expired sessions, although this interval is configurable.</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="_sessioncache"></a>SessionCache</h4></div></div></div><p>There is 1 <code class="literal">SessionCache</code> per context.
Its purpose is to provide an L1 cache of Session objects.
Having a working set of Session objects in memory allows multiple simultaneous requests for the same session to share the same Session object.</p><p>Jetty provides 2 <code class="literal">SessionCache</code> implementations: the <code class="literal">DefaultSessionCache</code> and the <code class="literal">NullSessionCache</code>.
The <code class="literal">DefaultSessionCache</code> retains Session objects in memory in a cache and has a number of configuration options to control cache behavior.
It is the default that is used if no other <code class="literal">SessionCache</code> has been configured.
It is suitable for non-clustered and clustered deployments with a sticky load balancer, as well as clustered deployments with a non-sticky load balancer, with some caveats.
The <code class="literal">NullSessionCache</code> does not actually cache any objects: each request uses a fresh Session object.
It is suitable for clustered deployments without a sticky load balancer and non-clustered deployments when purely minimal support for sessions is needed.</p><p><code class="literal">SessionCaches</code> always write out a Session to the <code class="literal">SessionDataStore</code> whenever the last request for the Session exits.</p><p>They can also be configured to do an immediate, eager write of a freshly created session.
This can be useful if you are likely to experience multiple, near simultaneous requests referencing the same session, e.g. with HTTP/2 and you don’t have a sticky load balancer.
Alternatively, if the eager write is not done, application paths which create and then invalidate a session within a single request never incur the cost of writing to persistent storage.</p><p>Additionally, if the <code class="literal">EVICT_ON_INACTIVITY</code> eviction policy is in use, you can configure the <code class="literal">DefaultSessionCache</code> to force a write of the Session to the SessionDataStore just before the Session is evicted.</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="_sessiondatastore"></a>SessionDataStore</h4></div></div></div><p>There is 1 <code class="literal">SessionDataStore</code> per context. Its purpose is to handle all persistence related operations on sessions.</p><p>The common characteristics for all <code class="literal">SessionDataStores</code> are whether or not they support passivation, and the length of the grace period.</p><p>Supporting passivation means that session data is serialized.
Some persistence mechanisms serialize, such as JDBC, GCloud Datastore etc, whereas others may store an object in shared memory eg Infinispan when configured with a local cache.</p><p>Whether or not a clustering technology entails passivation controls whether or not the session passivation/activation listeners will be called.</p><p>The grace period is an interval, configured in seconds, that attempts to deal with the non-transactional nature of sessions with regard to finding sessions that have expired.
Due to the lack of transactionality, in a clustered configuration, even with a sticky load balancer, it is always possible that a Session is live on a node but has not yet been updated in the persistent store.
When <code class="literal">SessionDataStores</code> search their persistent store to find sessions that have expired, they typically perform a few sequential searches:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem">The first verifies the expiration of a list of candidate session ids suggested by the SessionCache</li><li class="listitem">The second finds sessions in the store that have expired which were last live on the current node</li><li class="listitem">The third finds sessions that expired a "while" ago, irrespective of on which node they were last used: the definition of "a while" is based on the grace period.</li></ul></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="_cachingsessiondatastore"></a>CachingSessionDataStore</h4></div></div></div><p>The <code class="literal">CachingSessionDataStore</code> is a special type of <code class="literal">SessionDataStore</code> that inserts an L2 cache of SessionData - the <code class="literal">SessionDataMap</code> - in front of a delegate <code class="literal">SessionDataStore</code>.
The <code class="literal">SessionDataMap</code> is preferentially consulted before the actual SessionDataStore on reads.
This can improve the performance of slow stores.</p><p>Jetty provides one implementation of the this L2 cache based on <code class="literal">Memcached</code>, the <code class="literal">MemcachedSessionDataMap</code>.</p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="_use_cases"></a>Use Cases</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="_clustering_with_a_sticky_load_balancer"></a>Clustering with a Sticky Load Balancer</h4></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 might 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><h4 class="title"><a name="_clustering_without_a_sticky_load_balancer"></a>Clustering without a Sticky Load Balancer</h4></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-tuned 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><h4 class="title"><a name="_handling_corrupted_or_unloadable_session_data"></a>Handling corrupted or unloadable session data</h4></div></div></div><p>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 <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></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-management.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-sessions-memory.html">Next <i class="fa fa-chevron-right" aria-hidden="true"></i></a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 10. Session Management </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"> Non-Clustered Session Management: Memory</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: 2017-01-07)</i></span></div></p><script 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" type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-1149868-7']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script></body></html>
|
