Distributed Sessions and Persistence

---

Note –

Some topics in the documentation pertain to features that are available only in domains that are configured to support clusters. Examples of domains that support clusters are domains that are created with the cluster profile. For information about profiles, see Usage Profiles in Sun GlassFish Communications Server 2.0 Administration Guide.

---

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

• Each server instance has the same distributable web, SIP, or converged web/SIP application deployed to it. The web-app element of the web.xml or sip.xmldeployment descriptor file must have the distributable subelement specified. For a converged web/SIP application to be treated as distributable, both its web.xml and sip.xml deployment descriptor files must have the distributable subelement specified.

• The web, SIP, or converged web/SIP application uses high-availability session persistence. If a non-distributable web, SIP, or converged web/SIP 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.

• If a converged web/SIP application uses high-availability session persistence for its SIP sessions, but not its HTTP sessions, or the reverse, a warning is logged, and the persistence type of both the application's SIP and HTTP sessions reverts to memory.

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

• The web, SIP, or converged web/SIP application must be deployed using the deploy or deploydir command with the --availabilityenabled option set to true. See the Sun GlassFish Communications Server 2.0 Reference Manual.

---

Note –

Contrary to the Servlet 2.5 specification, Communications 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.

---

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, SIP, or converged web/SIP application references a Java EE component or resource, the reference might be lost. See Table 8–4 for a list of the types of references that HTTPSession or SipApplicationSessionfailover supports.

• References to open files or network connections are lost.

• Session replication occurs asynchronously, so a small number of sessions may be lost on failure because their state has not propagated to the other instances in the cluster.

For information about how to work around these limitations, see the Sun GlassFish Communications Server 2.0 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 16, Using the Transaction Service. For more information about Administered Objects, see Creating Physical Destinations.

Table 8–4 Object Types Supported for Java EE Web or SIP Application Session State Failover

Java Object Type	Failover Support
Colocated or distributed stateless session, stateful session, or entity bean 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
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