Coordinating Session Access

Make sure that multiple threads don’t simultaneously modify the same session object in
conflicting ways. If the persistence type is replicated (see The replicated Persistence Type), the following message
in the log file indicates that this might be happening:

Primary Key Constraint violation while saving session session_id

This is especially likely to occur in web applications that use HTML frames
where multiple servlets are executing simultaneously on behalf of the same client. A
good solution is to ensure that one of the servlets modifies the session
and the others have read-only access.

Saving Sessions During Redeployment

Whenever a redeployment is done, the sessions at that transit time become invalid
unless you use the --keepstate=true option of the asadmin redeploy command. For example:

The default for --keepstate is false. This option is supported only on the
default server instance, named server. It is not supported and ignored for any other
target.

For web applications, this feature is applicable only if in the glassfish-web-app.xml file
the persistence-type attribute of the session-manager element is file.

If any active web session fails to be preserved or restored, none
of the sessions will be available when the redeployment is complete. However, the
redeployment continues and a warning is logged.

The new class loader of the redeployed application is used to deserialize any
sessions previously saved. The usual restrictions about serialization and deserialization apply. For example,
any application-specific class referenced by a session attribute may evolve only in a
backward-compatible fashion. For more information about class loaders, see Chapter 2, Class Loaders.

Logging Session Attributes

You can write session attribute values to an access log. The access log
format token %session.name% logs one of the following:

The value of the session attribute with the name name

NULL-SESSION-ATTRIBUTE-name if the named attribute does not exist in the session

NULL-SESSION if no session exists

For more information about access logging and format tokens, see online help for
the Access Log tab of the HTTP Service page in the Administration Console.

Distributed Sessions and Persistence

A distributed HTTP session can run in multiple GlassFish Server instances, provided the
following criteria are met:

Each server instance has the same distributable web application deployed to it. The web-app element of the web.xml deployment descriptor file must have the distributable subelement specified.

The web application uses high-availability session persistence. If a non-distributable web application is configured to use high-availability session persistence, a warning is written to the server log, and the session persistence type reverts to memory. See The replicated Persistence Type.

All objects bound into a distributed session must be of the types listed in Table 7-3.

In the following table, No indicates that failover for the object type might
not work in all cases and that no failover support is provided. However,
failover might work in some cases for that object type. For example, failover
might work because the class implementing that type is serializable.

Yes, but if the instance that fails is never restarted, any prepared global
transactions are lost and might not be correctly rolled back or committed.

JDBC DataSource

No

Java
Message Service (JMS) ConnectionFactory, Destination

No

JavaMail Session

No

Connection Factory

No

Administered Object

No

Web service reference

No

Serializable Java types

Yes

Extended
persistence context

No

Session Managers

A session manager automatically creates new session objects whenever a new session starts.
In some circumstances, clients do not join the session, for example, if the
session manager uses cookies and the client does not accept cookies.

The memory Persistence Type

This persistence type is not designed for a production environment that requires session
persistence. It provides no session persistence. However, you can configure it so that
the session state in memory is written to the file system prior to
server shutdown.

To specify the memory persistence type for a specific web application, edit the
glassfish-web.xml file as in the following example. The persistence-type attribute is optional, but must
be set to memory if included. This overrides the web container availability settings
for the web application.

The only manager property that the memory persistence type supports is sessionFilename, which
is listed under manager-properties in Oracle GlassFish Server 3.1 Application Deployment Guide. The sessionFilename property specifies the name of the file where sessions
are serialized and persisted if the web application or the server is stopped.
To disable this behavior, specify an empty string as the value of sessionFilename. The
default value is an empty string.

The file Persistence Type

This persistence type provides session persistence to the local file system, and allows
a single server domain to recover the session state after a failure and
restart. The session state is persisted in the background, and the rate at
which this occurs is configurable. The store also provides passivation and activation of
the session state to help control the amount of memory used. This option
is not supported in a production environment. However, it is useful for a development
system with a single server instance.

Note - Make sure the delete option is set in the server.policy file, or expired
file-based sessions might not be deleted properly. For more information about server.policy, see
The server.policy File.

To specify the file persistence type for a specific web application, edit the
glassfish-web.xml file as in the following example. Note that persistence-type must be set to
file. This overrides the web container availability settings for the web application.

The replicated Persistence Type

The replicated persistence type uses other servers in the cluster for session persistence.
Clustered server instances replicate session state. Each backup instance stores the replicated
data in memory. This allows sessions to be distributed. For details, see Distributed Sessions and Persistence.
In addition, you can configure the frequency and scope of session persistence. The other
servers are also used as the passivation and activation store. Use this option
in a production environment that requires session persistence.

To use the replicated persistence type, you must enable availability. Select the Availability
Service component under the relevant configuration in the Administration Console. Check the Availability
Service box. To enable availability for the web container, select the Web Container
Availability tab, then check the Availability Service box. All instances in an GlassFish
Server cluster should have the same availability settings to ensure consistent behavior. For details,
see the Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide.

To change settings such as persistence frequency and persistence scope for the entire
web container, use the Persistence Frequency and Persistence Scope drop-down lists on the
Web Container Availability tab in the Administration Console, or use the asadmin set command. For
example:

asadmin set
server-config.availability-service.web-container-availability.persistence-frequency=time-based

To specify the replicated persistence type for a specific web application, edit the
glassfish-web.xml file as in the following example. Note that persistence-type must be set to
replicated. This overrides the web container availability settings for the web application.

To specify that web sessions for which high availability is enabled are first
buffered and then replicated using a separate asynchronous thread, use the --asyncreplication=true option of
the asadmin deploy command. For example:

If --asyncreplication is set to true (the default), performance is improved but availability
is reduced. If the instance where states are buffered but not yet replicated fails,
the states are lost. If set to false, performance is reduced but availability
is guaranteed. States are not buffered but immediately transmitted to other instances in
the cluster.

The coherence-web Persistence Type

Built on top of Oracle Coherence, Coherence*Web is an HTTP session management module
dedicated to managing session state in clustered environments. Starting with Coherence 3.7 and
GlassFish Server 3.1, there is a new feature of Coherence*Web called ActiveCache for
GlassFish. ActiveCache for GlassFish provides Coherence*Web functionality in web applications deployed on GlassFish Servers.
Within GlassFish Server, Coherence*Web functions as an additional web container persistence type, named coherence-web.