Message-ID: <1242697082.445.1369165391290.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_444_1186447811.1369165391290" ------=_Part_444_1186447811.1369165391290 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
|This feature is only available since r=
Jetty can support session clustering by persisting sessions to a shared = database. Each jetty instance locally caches sessions for which it has rece= ived requests, writing any changes to the session through to the database a= s the request exits the server. Sessions must obey the Serialization contra= ct, and servlets must call the Session.setAttribute() method to ensure that= changes are persisted.
The persistent session mechanism is designed to work in conjunction with= a load balancer that supports stickiness. Stickiness can be based on vario= us data items, such as source IP address or characteristics of the session = id or a load-balancer specific mechanism. For those load balancers that exa= mine the session id, the Jetty persistent session mechanism appends a node = id to the session id which can be used for routing.
It should be noted that in this type of solution, the database can becom= e both a bottleneck and a single point of failure. Jetty takes steps to try= to reduce the load on the database (discussed below), but in a heavily loa= ded environment you may need to investigate other optimisation strategies s= uch as local caching and database replication. You should also consult your= database vendor's documentation for information on how to ensure high-avai= lability and fail-over of your database.
There are 2 components to session management in Jetty: a session id mana= ger and a session manager. The session id manager's job is to ensure that s= ession ids are unique across all webapps hosted on a jetty instance and thu= s there can only be one per jetty instance. The session manager's job is to= handle the session lifecycle (create/update/invalidate/expire) on behalf o= f a web application, and thus there is one per web application instance. Th= ey also cooperate and collaborate with the org.mortbay.handler.SessionHandl= er to enable cross-context dispatch.
We need to configure an org.mortbay.jetty.servlet.JDBCSessionIdManager i= nstance, either in embedded code or in a jetty.xml file. Here is an example= of a jetty.xml setup:
You'll notice that the JDBCSessionIdManager needs access to a database. = The above configures it with the name of a javax.sql.DataSource that is def= ined elsewhere. Consult Jetty Naming Resour= ces for more information on how to configure database access with jetty= . If you don't wish to use a DataSource, you can configure jdbc Driver info= rmation instead. Here's an example:
As jetty config files are direct mappings of xml to java, it is quite st= raightforward to see how this would be done in code, but here's an example = anyway:
The JDBCSessionIdManager MUST be configured with a workerName which is a name unique across the cluster. Typically it relates to t= he physical node on which the instance is executing. If this name is not un= ique, your load balancer may fail to distribute your sessions correctly.
You can also configure how often the persistent session mechanism sweeps= the database looking for old, expired sessions with the scavengeIn= terval setting. By default, this is set to 60seconds. We recommend that you do not increase the frequency as you will increa= se the load on the database with very little gain, as old expired sessions = can harmlessly sit in the database.
The way you configure a JDBCSessionManager is a little different dependi= ng on whether you're configuring from a context xml file or a jetty-web.xml= file, or code. The basic difference is how you get a reference to the Jett= y org.mortbay.jetty.server.Jetty instance.
From a context xml file, you reference the Server instance as a Property= :
From a WEB-INF/jetty-web.xml file, you can reference the Server instance= directly:
If you're embedding this in code:------=_Part_444_1186447811.1369165391290--