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

- Previous: Coordinating Session Access
- Next: Session Managers

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

- Previous: Coordinating Session Access
- Next: Session Managers

- © 2010, Oracle Corporation and/or its affiliates