Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer's Guide

- Previous: Using JavaServer Pages
- Next: Chapter 6 Using Enterprise JavaBeans Technology

# Creating and Managing HTTP Sessions

This chapter describes how to create and manage a session that allows users and transaction information to persist between interactions.

This chapter contains the following sections:

- Configuring Sessions

- Session Managers

- Sample Session Persistence Applications

## Configuring Sessions

This section covers the following topics:

- Sessions, Cookies, and URL Rewriting

- Coordinating Session Access

- Distributed Sessions and Persistence

### Sessions, Cookies, and URL Rewriting

To configure whether and how sessions use cookies and URL rewriting, edit the `session-properties` and `cookie-properties` elements in the `sun-web.xml` file for an individual web application. See session-properties and cookie-properties for more about the properties you can configure.

For information about configuring default session properties for the entire web container, see the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Administration Guide and the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 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 `ha` (see The ha 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.

### Distributed Sessions and Persistence

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

- Each server instance has access to the same high-availability database (HADB). For information about how to enable this database, see the description of the `configure-ha-cluster` command in the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Reference Manual.

- 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, an error is written to the server log. See The ha Persistence Type.

- All objects bound into a distributed session must be of the types listed in Table 5–4.

- The web application must be deployed using the `deploy` or `deploydir` command with the `--availabilityenabled` option set to `true`. See the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Reference Manual.

Note –

Contrary to the Servlet 2.4 specification, Application Server does not throw an `IllegalArgumentException` if an object type not supported for failover is bound into a distributed session.

Keep the distributed session size as small as possible. Session size has a direct impact on overall system throughput.

A servlet that is not deployed as part of a web application is implicitly deployed to a default web application and has the default `ServletContext`. The default `ServletContext` is not distributed. (A web application with an empty context root does not have the default `ServletContext`.)

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 J2EE component or resource, the reference might be lost. See Table 5–4 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 Sun Java System Application Server Enterprise Edition 8.1 2005Q2 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 12, Using the Transaction Service. For more information about Administered Objects, see Creating Physical Destinations.

Table 5–4 Object Types Supported for J2EE Web Application Session State Failover

Java Object Type | Failover Support
--- | ---
Stateless session, stateful session, and entity bean local home reference, local object reference | Yes
Colocated and distributed stateless session, stateful session, and entity bean remote home reference, remote reference | Yes
JNDI Context | Yes, `InitialContext` and `java:comp/env`
UserTransaction | 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
JavaTM Message Service (JMS) ConnectionFactory, Destination | No
JavaMailTM Session | No
Connection Factory | No
Administered Object | No
Web service reference | No
Serializable Java types | Yes

## 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.

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

- The memory Persistence Type, the default

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

- The ha Persistence Type, which uses the high-availability database for session persistence

Note –

If the session manager configuration contains an error, the error is written to the server log and the default (`memory`) configuration is used.

### 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 the entire web container, use the `configure-ha-persistence` command. For details, see the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Reference Manual.

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

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

The only manager property that the `memory` persistence type supports is sessionFilename, which is listed under manager-properties.

For more information about the `sun-web.xml` file, see The sun-web.xml File.

### 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 the entire web container, use the `configure-ha-persistence` command. For details, see the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Reference Manual.

To specify the `file` persistence type for a specific web application, edit the `sun-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.

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

The `file` persistence type supports all the manager properties listed under manager-properties except `sessionFilename`, and supports the `directory` store property listed under store-properties.

For more information about the `sun-web.xml` file, see The sun-web.xml File.

### The ha Persistence Type

The ha persistence type uses the high-availability database (HADB) for session persistence. The HADB 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 HADB is also used as the passivation and activation store. Use this option in a production environment that requires session persistence.

The HADB must be configured and enabled before you can use distributed sessions. For configuration details, see the description of the `configure-ha-cluster` command in the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Reference Manual.

To enable the HADB, select the Availability Service component under the relevant configuration in the Administration Console. Check the Instance Level Availability box. To enable availability for the web container, select the Web Container Availability tab, then check the Availability Service box. For details, see the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 High Availability Administration Guide.

To change settings such as persistence frequency and persistence scope for the entire web container, see the description of the `configure-ha-persistence` command in the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Reference Manual.

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

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

The `ha` persistence type supports all the manager properties listed under manager-properties except `sessionFilename`, and supports the `persistenceScope` store property listed under store-properties.

For more information about the `sun-web.xml` file, see The sun-web.xml File.

## Sample Session Persistence Applications

The following directories contain sample applications that demonstrate HTTP session persistence:

    install-dir/samples/ee-samples/highavailability

    install-dir/samples/ee-samples/failover

- Previous: Using JavaServer Pages
- Next: Chapter 6 Using Enterprise JavaBeans Technology

- © 2010, Oracle Corporation and/or its affiliates