resin

$resin/ref/sessions.xtp

Sessions can be persistent across server restarts, including application restarts when classes change. During development, for example, using file-based persistent sessions will let you work with a single session even while you're modifying servlet classes.

CREATE TABLE persistent_session ( id VARCHAR(64) NOT NULL, data BLOB, access_time int(11), expire_interval int(11), PRIMARY KEY(id) )

The store is enabled with <use-persistent-store> in the session config. <web-app xmlns="http://caucho.com/ns/resin"> <session-config> <use-persistent-store/> <always-save-session/> </session-config> </web-app>

The distributed cluster stores the sessions across the cluster servers. In some configurations, the cluster store may be more efficient than the database store, in others the database store will be more efficient.

With cluster sessions, each session has an owning JVM and a backup JVM. The session is always stored in both the owning JVM and the backup JVM.

The cluster store is configured in the in the <server>. It uses the <srun> hosts in the server's <cluster> to distribute the sessions. The session store is enabled in the <session-config> with the <use-persistent-store>.

<resin xmlns="http://caucho.com/ns/resin"> ... <server> <cluster> <srun id="a" host="192.168.0.1" port="6802" index="1"/> <srun id="b" host="192.168.0.2" port="6802" index="2"/> </cluster> <persistent-store type="cluster"> <init path="cluster"/> </persistent-store> ...

The configuration is enabled in the web-app.

<web-app xmlns="http://caucho.com/ns/resin"> <session-config> <use-persistent-store="true"/> </session-config> </web-app>

The <srun> and <srun-backup> hosts are treated as a cluster of hosts. Each host uses the other hosts as a backup. When the session changes, the updates will be sent to the backup host. When the host starts, it looks up old sessions in the other hosts to update its own version of the persistent store.

More details on the tcp-based sessions are in the TCP-sessions page.

Copyright (c) 1998-2009 Caucho Technology, Inc. All rights reserved.
caucho_® , resin_® and quercus_® are registered trademarks of Caucho Technology, Inc.

Configuration for persistent store uses the persistent-store tag.

For single-server configurations
Useful in development when classes change often

Persistent sessions are configured in the web-app. File-based sessions use file-store.

<web-app xmlns="http://caucho.com/ns/resin"> <session-config> <file-store>WEB-INF/sessions</file-store> </session-config> </web-app>

Sessions are stored as files in the file-store directory. When the session changes, the updates will be written to the file. After Resin loads an Application, it will load the stored sessions.

File-based persistence is not useful in multi-server environments. Although a network filesystem such as NFS will allow all the servers to access the same filesystem, it's not designed for the fine-grained access. For example, NFS will cache pages. So if one server modifies the page, e.g. a session value, the other servers may not see the change for several seconds.

Distributed sessions are intrinsically more complicated than single-server sessions. Single-server session can be implemented as a simple memory-based Hashtable. Distributed sessions must communicate between machines to ensure the session state remains consistent.

Load balancing with multiple machines either uses sticky sessions or symmetrical sessions. Sticky sessions put more intelligence on the load balancer, and symmetrical sessions puts more intelligence on the JVMs. The choice of which to use depends on what kind of hardware you have, how many machines you're using and how you use sessions.

Distributed sessions can use a database as a backing store, or they can distribute the backup among all the servers using TCP.

Symmetrical sessions happen with dumb load balancers like DNS round-robin. A single session may bounce from machine A to machine B and back to machine B. For JDBC sessions, the symmetrical session case needs the always-load-session attribute described below. Each request must load the most up-to-date version of the session.

Distributed sessions in a symmetrical environment are required to make sessions work at all. Otherwise the state will end up spread across the JVMs. However, because each request must update its session information, it is less efficient than sticky sessions.

Sticky sessions require more intelligence on the load-balancer, but are easier for the JVM. Once a session starts, the load-balancer will always send it to the same JVM. Resin's load balancing, for example, encodes the session id as 'aaaXXX' and 'baaXXX'. The 'aaa' session will always go to JVM-a and 'baa' will always go to JVM-b.

Distributed sessions with a sticky session environment add reliability. If JVM-a goes down, JVM-b can pick up the session without the user noticing any change. In addition, distributed sticky sessions are more efficient. The distributor only needs to update sessions when they change. So if you update the session once when the user logs in, the distributed sessions can be very efficient.

Symmetrical sessions must use the 'always-load-session' flag to update each session data on each request. always-load-session is only needed for jdbc-store sessions. tcp-store sessions use a more-sophisticated protocol that eliminates the need for always-load-session, so tcp-store ignores the always-load-session flag.

The always-load-session attribute forces sessions to check the store for each request. By default, sessions are only loaded from persistent store when they are created. In a configuration with multiple symmetric web servers, sessions can be loaded on each request to ensure consistency.

By default, Resin only saves session data when you add new values to the session object, i.e. if the request calls setAttribute. This may be insufficient when storing large objects. For example, if you change an internal field of a large object, Resin will not automatically detect that change and will not save the session object.

With always-save-session Resin will always write the session to the store at the end of each request. Although this is less efficient, it guarantees that updates will get stored in the backup after each request.

Database backed sessions are the easiest to understand. Session data gets serialized and stored in a database. The data is loaded on the next request.

For efficiency, the owning JVM keeps a cache of the session value, so it only needs to query the database when the session changes. If another JVM stores a new session value, it will notify the owner of the change so the owner can update its cache. Because of this notification, the database store is cluster-aware.

In some cases, the database can become a bottleneck. By adding load to an already-loaded system, you may harm performance. One way around that bottleneck is to use a small, quick database like MySQL for your session store and save the "Big Iron" database like Oracle for your core database needs.

The database must be specified using a <database>. The database store will automatically create a session table.

The JDBC store needs to know about the other servers in the cluster in order to efficiently update them when changes occur to the server.

<resin xmlns="http://caucho.com/ns/resin"> <server> <http id='a' port='80'/> <http id='b' port='80'/> <database jndi-name="jdbc/session"> ... </database> <cluster> <srun id='a' host='host-a' port='6802'/> <srun id='b' host='host-b' port='6802'/> </cluster> <persistent-store type="jdbc"> <init> <data-source>jdbc/session<data-source> </init> </persistent-store> ... <web-app-default> <session-config> <use-persistent-store/> </session-config> </web-app-default>

The persistent store is configured in the <server> with persistent-store. Each web-app which needs distributed sessions must enable the persistent store with a use-persistent-store tag in the session-config.

data-source

data source name for the table

table-name

database table for the session data

blob-type

database type for a blob

max-idle-time

cleanup time