HTTP Session Management
The XAP-Jetty integration comes with a support for storing the javax.servlet.http.HttpSession in the Space allowing supporting session replication and failover between different web application instances deployed into XAP containers.
The XAP HTTP Session Management provides the following:
- Avoid using database as the persistent storage media - Better performance and simplify the deployment
- Allow management and control of full lifecycle of web application - From the load-balancer to the data
- Dynamic scalability - Allows the web application to scale up or down based on SLA
- Continuous High-Availability - Allows the application to survive any system failures
- Non intrusive session management or explicit Data Grid API access for fine grain control - Allows multiple web servers to share the same session in transparent manner
For global HTTP Session Managment for Tomcat , JBoss , Weblogic , Websphere , Glassfish and other J2EE web/application servers see the Global Http Session Sharing.
How to enable XAP’s HTTP Session Management
There are several ways to configure Space session based support, depending on the definition of which Space and how the Space was started.
Using Deploy property
Here is how you can deploy an existing WAR file without changing it (or use Spring) to use XAP HTTP Session Management:
gs deploy -properties embed://jetty.sessions.spaceUrl=jini://*/*/sessionSpace?useLocalCache myWar.war
When deploying, include within the
META-INF/spring/pu.properties file the
jetty.sessions.spaceUrl property value. This should be set with the space url defining where the sessions will be stored.
For example, if the session will be stored on a remote clustered Space with local cache, the URL can be:
jini://*/*/sessionSpace?useLocalCache (assuming the name of the Space is sessionSpace). If the session should be stored on a Space that should be started within the web application (in a collocated manner) in a sync_replicated cluster schema (for example), then the url can be
/./sessionSpace?cluster_schema=sync_replicated (note, cluster ids will be automatically set based on the number of web applications deployed).
In case there is already a Space configured within the web application. For example, defined within
META-INF/spring/pu.xml, it can be used as the Space where sessions will be stored as well. In this case, the
jetty.sessions.spaceUrl can use the special prefix
bean. For example, if the Space was defined as a bean with id of
jetty.sessions.spaceUrl can be set to
See the Quick Start Guide for an example how to use the HTTP Session Management.
Controlling the session Management done via the following properties:
||specifies the URL of the space with the HTTP session store will be backed. Use the
||Determines how often the web container will check for expired sessions. Set in seconds.||300 seconds (5 minutes)||No|
||How often an actual update of a non dirty session will be performed to the Space. Set in seconds||60 seconds. This is useful for cases where a session attribute is not updated explicitly using the
||Determines the HTTP session timeout in minutes (similar to
||The lease of the SessionData that is written to the Space||Long.MAX_VALUE||No|
XAP integration implements Jetty
GigaSessionIdManager. When setting the
jetty.sessions.spaceUrl they get automatically set as the session manager and session id manager of the web app.
The HTTP Session support several Deployment Topologies:
- Support only Limited amount of Sessions
- Session Data is partitioned across multiple machines
- Allows unlimited amount of data to be stored in memory
Partitioned+Replicated with Local-Cache
Support for read mostly scenario via local cache running within the application server memory address. Avoid remote calls when there are repeated read calls for Session data that are stored in memory across multiple machines.
Provide total linear scalability.