Creating and Managing Sessions

This section describes how to create and manage HTTP sessions that allows users and transaction information to persist between interactions.

The following topics are addressed here:

• Configuring Sessions

• Session Managers

Configuring Sessions

The following topics are addressed here:

• HTTP Sessions, Cookies, and URL Rewriting

• Coordinating Session Access

• Saving Sessions During Redeployment

• Logging Session Attributes

• Distributed Sessions and Persistence

HTTP Sessions, Cookies, and URL Rewriting

To configure whether and how HTTP sessions use cookies and URL rewriting, edit the session-properties and cookie-properties elements in the glassfish-web.xml file for an individual web application. For more about the properties you can configure, see session-properties in Oracle GlassFish Server 3.1 Application Deployment Guide and cookie-properties in Oracle GlassFish Server 3.1 Application Deployment Guide.

For information about configuring default session properties for the entire web container, see Using the default-web.xml File and the Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide.

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:

asadmin redeploy --keepstate=true --name hello.war

For details, see the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.

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.

• The web application must be deployed using the deploy or deploydir command with the --availabilityenabled option set to true. See the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.

In the event of an instance or hardware failure, another server instance can take over a distributed session, with the following limitations:

• If a distributable web application references a Java EE component or resource, the reference might be lost. See Table 7-3 for a list of the types of references that HTTPSession failover supports.

• References to open files or network connections are lost.

For information about how to work around these limitations, see the Oracle GlassFish Server 3.1 Deployment Planning Guide.

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.

For more information about the InitialContext, see Accessing the Naming Context. For more information about transaction recovery, see Chapter 15, Using the Transaction Service. For more information about Administered Objects, see Administering JMS Physical Destinations in Oracle GlassFish Server 3.1 Administration Guide.

Table 7-3 Object Types Supported for Java EE Web Application Session State Failover

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.

GlassFish Server offers these session management options, determined by the session-manager element’s persistence-type attribute in the glassfish-web.xml file:

• The memory Persistence Type, the default

• The file Persistence Type, which uses a file to store session data

• The replicated Persistence Type, which uses other servers in the cluster for session persistence

• The coherence-web Persistence Type, which uses Coherence*Web for session persistence

For more information, see session-manager in Oracle GlassFish Server 3.1 Application Deployment Guide.

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.

<glassfish-web-app>
...
<session-config>
    <session-manager persistence-type="memory" />
        <manager-properties>
            <property name="sessionFilename" value="sessionstate" />
        </manager-properties>
    </session-manager>
    ...
</session-config>
...
</glassfish-web-app>

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.

For more information about the glassfish-web.xml file, see Oracle GlassFish Server 3.1 Application Deployment Guide.

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.

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.

<glassfish-web-app>
...
<session-config>
    <session-manager persistence-type="file">
        <store-properties>
            <property name="directory" value="sessiondir" />
        </store-properties>
    </session-manager>
    ...
</session-config>
...
</glassfish-web-app>

The file persistence type supports all the manager properties listed under manager-properties in Oracle GlassFish Server 3.1 Application Deployment Guide except sessionFilename, and supports the directory store property listed under store-properties in Oracle GlassFish Server 3.1 Application Deployment Guide.

For more information about the glassfish-web.xml file, see Oracle GlassFish Server 3.1 Application Deployment Guide.

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

For more information, see the description of the asadmin set command in the Oracle GlassFish Server 3.1-3.1.1 Reference Manual.

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.

<glassfish-web-app>
...
<session-config>
    <session-manager persistence-type="replicated">
        <manager-properties>
            <property name="persistenceFrequency" value="web-method" />
        </manager-properties>
        <store-properties>
            <property name="persistenceScope" value="session" />
        </store-properties>
    </session-manager>
    ...
</session-config>
...
</glassfish-web-app>

The replicated persistence type supports all the manager properties listed under manager-properties in Oracle GlassFish Server 3.1 Application Deployment Guide except sessionFilename, and supports the persistenceScope store property listed under store-properties in Oracle GlassFish Server 3.1 Application Deployment Guide.

For more information about the glassfish-web.xml file, see Oracle GlassFish Server 3.1 Application Deployment Guide.

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:

asadmin deploy --availabilityenabled=true --asyncreplication=true --name hello.war

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.

For information about how to configure and deploy Coherence*Web on GlassFish Server, see Using Coherence*Web with GlassFish Server.