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