Version: 9.4.5.v20170502 |

Clustered Session Management: JDBC
Previous | Chapter 10. Session Management Home | Next

##### Contact the core Jetty developers at www.webtide.com

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

## Clustered Session Management: JDBC

### Enabling JDBC Sessions

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.

### Configuring JDBC Session Properties

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

jetty.session.gracePeriod.seconds
  Amount of time, in seconds, to wait for other nodes to be checked to verify an expired session is in fact expired throughout the cluster before closing it.
jetty.session.savePeriod.seconds=0

  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 to `savePeriod` 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 the `maxIdleTime` of the session when setting the `savePeriod` is imperative - there is no point in setting a `savePeriod` that is larger than the `maxIdleTime`.

db-connection-type
  Set to either `datasource` or `driver` depending on the type of connection being used.
jetty.session.jdbc.datasourceName
  Name of the remote datasource.
jetty.session.jdbc.driverClass
  Name of the JDBC driver that controls access to the remote database, such as `com.mysql.jdbc.Driver`
jetty.session.jdbc.driverUrl
  Url of the database which includes the driver type, host name and port, service name and any specific attributes unique to the database, such as a username. As an example, here is a mysql connection with the username appended: `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.

Previous | Top | Next
Non-Clustered Session Management: File System | Home | Clustered Session Management: MongoDB

See an error or something missing? Contribute to this documentation at Github!(Generated: 2017-05-02)