Version: 9.4.5.v20170502 |
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
When using the Jetty distribution, you will first need to enable the session-store-jdbc
module for your Jetty base using the --add-to-start
argument on the command line.
$ java -jar ../start.jar --create-startd INFO : Base directory was modified $ java -jar ../start.jar --add-to-start=session-store-jdbc INFO : server transitively enabled, ini template available with --add-to-start=server INFO : sessions transitively enabled, ini template available with --add-to-start=sessions INFO : sessions/jdbc/datasource dynamic dependency of session-store-jdbc INFO : session-store-jdbc initialized in ${jetty.base}/start.d/session-store-jdbc.ini INFO : Base directory was modified
Doing this enables the JDBC Session module and any dependent modules or files needed for it to run on the server.
The example above is using a fresh ${jetty.base}
with nothing else enabled.
When the --add-to-start
argument was added to the command line, it enabled the the session-store-jdbc
module as well as the sessions
and server
modules, which are required for JDBC session management to operate.
In addition to adding these modules to the classpath of the server, several ini configuration files were added to the ${jetty.base}/start.d
directory.
Opening the start.d/session-store-jdbc.ini
will show a list of all the configurable options for the JDBC module:
# --------------------------------------- # Module: session-store-jdbc # Enables JDBC peristent/distributed session storage. # --------------------------------------- --module=session-store-jdbc ## ##JDBC Session properties ## #jetty.session.gracePeriod.seconds=3600 ## Connection type:Datasource db-connection-type=datasource #jetty.session.jdbc.datasourceName=/jdbc/sessions ## Connection type:driver #db-connection-type=driver #jetty.session.jdbc.driverClass= #jetty.session.jdbc.driverUrl= ## Session table schema #jetty.session.jdbc.schema.accessTimeColumn=accessTime #jetty.session.jdbc.schema.contextPathColumn=contextPath #jetty.session.jdbc.schema.cookieTimeColumn=cookieTime #jetty.session.jdbc.schema.createTimeColumn=createTime #jetty.session.jdbc.schema.expiryTimeColumn=expiryTime #jetty.session.jdbc.schema.lastAccessTimeColumn=lastAccessTime #jetty.session.jdbc.schema.lastSavedTimeColumn=lastSavedTime #jetty.session.jdbc.schema.idColumn=sessionId #jetty.session.jdbc.schema.lastNodeColumn=lastNode #jetty.session.jdbc.schema.virtualHostColumn=virtualHost #jetty.session.jdbc.schema.maxIntervalColumn=maxInterval #jetty.session.jdbc.schema.mapColumn=map #jetty.session.jdbc.schema.table=JettySessions
By default whenever the last concurrent request leaves a session, that session is always persisted via the SessionDataStore
, even if the only thing that changed on the session is its updated last access time.
A non-zero value means that the SessionDataStore
will skip persisting the session if only the access time changed, and it has been less than savePeriod
seconds since the last time the session was written.
Note
Configuring
savePeriod
is useful if your persistence technology is very slow/costly for writes. In a clustered environment, there is a risk of the last access time of the session being out-of-date in the shared store for up tosavePeriod
seconds. This allows the possibility that a node may prematurely expire the session, even though it is in use by another node. Thorough consideration of themaxIdleTime
of the session when setting thesavePeriod
is imperative - there is no point in setting asavePeriod
that is larger than themaxIdleTime
.
datasource
or driver
depending on the type of connection being used.com.mysql.jdbc.Driver
jdbc:mysql://127.0.0.1:3306/sessions?user=sessionsadmin
.The jetty.sessionTableSchema
values represent the names for the columns in the JDBC database and can be changed to suit your environment.