Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Jetty/Howto/Persisting Sessions"
Line 4: | Line 4: | ||
| steps = | | steps = | ||
− | ==Enabling Persistence== | + | ===Enabling Persistence=== |
A SessionManager does just what it's name suggests - it manages the lifecycle and state of Sessions on behalf of a webapp. Each webapp must have it's own unique SessionManager instance. Enabling persistence is as simple as configuring the HashSessionManager as the SessionManager for a webapp and telling it where on disk to store the sessions: | A SessionManager does just what it's name suggests - it manages the lifecycle and state of Sessions on behalf of a webapp. Each webapp must have it's own unique SessionManager instance. Enabling persistence is as simple as configuring the HashSessionManager as the SessionManager for a webapp and telling it where on disk to store the sessions: | ||
Line 32: | Line 32: | ||
The above example uses a configuration file suitable for the [[http://dev.eclipse.org/viewcvs/index.cgi/jetty/trunk/jetty-deploy/src/main/java/org/eclipse/jetty/deploy/ContextDeployer.java?root=RT_JETTY&view=markup|org.eclipse.jetty.deploy.ContextDeployer]], thus you might want to check out the [[Jetty/Feature/ContextDeployer|Context Deployer]] feature guide. | The above example uses a configuration file suitable for the [[http://dev.eclipse.org/viewcvs/index.cgi/jetty/trunk/jetty-deploy/src/main/java/org/eclipse/jetty/deploy/ContextDeployer.java?root=RT_JETTY&view=markup|org.eclipse.jetty.deploy.ContextDeployer]], thus you might want to check out the [[Jetty/Feature/ContextDeployer|Context Deployer]] feature guide. | ||
− | ==Delaying Session Load== | + | ===Delaying Session Load=== |
Sometimes you may need to ensure that the sessions are loaded AFTER the servlet environment has been started up (by default, sessions will be eagerly loaded as part of the container startup, but before the servlet environment has been initialized). For example, the Wicket web framework requires the servlet environment to be available when sessions are activated. | Sometimes you may need to ensure that the sessions are loaded AFTER the servlet environment has been started up (by default, sessions will be eagerly loaded as part of the container startup, but before the servlet environment has been initialized). For example, the Wicket web framework requires the servlet environment to be available when sessions are activated. | ||
Line 50: | Line 50: | ||
</source> | </source> | ||
− | ==Enabling Persistence for the Maven Jetty Plugin== | + | ===Enabling Persistence for the Maven Jetty Plugin=== |
To enable session persistence for the maven jetty plugin, set up the HashSessionManager in the <configuration> section like so: | To enable session persistence for the maven jetty plugin, set up the HashSessionManager in the <configuration> section like so: |
Revision as of 12:34, 21 June 2010
Contents
Introduction
It can sometimes be useful to be able to preserve existing Sessions across restarts of Jetty. The org.eclipse.jetty.server.session.HashSessionManager supports this feature. If persistence is enabled, the HashSessionManager will save all existing, valid Sessions to disk before shutdown completes. On restart, the saved Sessions are restored.
Steps
Enabling Persistence
A SessionManager does just what it's name suggests - it manages the lifecycle and state of Sessions on behalf of a webapp. Each webapp must have it's own unique SessionManager instance. Enabling persistence is as simple as configuring the HashSessionManager as the SessionManager for a webapp and telling it where on disk to store the sessions:
<Configure class="org.mortbay.jetty.webapp.WebAppContext"> . . . <Set name="sessionHandler"> <New class="org.mortbay.jetty.servlet.SessionHandler"> <Arg> <New class="org.mortbay.jetty.servlet.HashSessionManager"> <Set name="storeDirectory">your/chosen/directory/goes/here</Set> </New> </Arg> </New> </Set> . . . </Configure>
The above example uses a configuration file suitable for the [[1]], thus you might want to check out the Context Deployer feature guide.
Delaying Session Load
Sometimes you may need to ensure that the sessions are loaded AFTER the servlet environment has been started up (by default, sessions will be eagerly loaded as part of the container startup, but before the servlet environment has been initialized). For example, the Wicket web framework requires the servlet environment to be available when sessions are activated.
Using SessionManager.setLazyLoad(true), sessions will be loaded lazily either when the first request for a session is received, or the session scavenger runs for the first time, whichever happens first. Here's how the configuration looks in xml:
<Set name="sessionHandler"> <New class="org.mortbay.jetty.servlet.SessionHandler"> <Arg> <New class="org.mortbay.jetty.servlet.HashSessionManager"> <Set name="lazyLoad">true</Set> </New> </Arg> </New> </Set>
Enabling Persistence for the Maven Jetty Plugin
To enable session persistence for the maven jetty plugin, set up the HashSessionManager in the <configuration> section like so:
<plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>maven-jetty-plugin</artifactId> <version>6.1.6</version> <configuration> <scanIntervalSeconds>1</scanIntervalSeconds> <webAppConfig implementation="org.mortbay.jetty.plugin.Jetty6PluginWebAppContext"> <contextPath>/foo</contextPath> . . . <sessionHandler implementation="org.mortbay.jetty.servlet.SessionHandler"> <sessionManager implementation="org.mortbay.jetty.servlet.HashSessionManager"> <storeDirectory>${basedir}/target/your/sessions/go/here</storeDirectory> </sessionManager> </sessionHandler> . . . </webAppConfig> </configuration> </plugin>