Configuring Sessions
This section covers the following topics:
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 sun-web.xml file for an individual web application. For more about the properties you can configure, see session-properties in Sun GlassFish Enterprise Server v2.1.1 Application Deployment Guide and cookie-properties in Sun GlassFish Enterprise Server v2.1.1 Application Deployment Guide.
For information about configuring default session properties for the entire web container, see Chapter 8, SIP, Web, and EJB Containers, in Sun GlassFish Enterprise Server v2.1.1 Administration Guide and the Sun GlassFish Enterprise Server v2.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 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 SIP applications where multiple SIP sessions share a SIP application session, and in converged applications where requests for the same session occur through HTTP and SIP protocols. It is likely to occur in pure 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
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 or the enterprise profile. For information about profiles, see Usage Profiles in Sun GlassFish Enterprise Server v2.1.1 Administration Guide.
A distributed HTTP session can run in multiple Enterprise 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 or The ha Persistence Type.
-
All objects bound into a distributed session must be of the types listed in Table 8–4.
-
The web application must be deployed using the deploy or deploydir command with the --availabilityenabled option set to true. See the Sun GlassFish Enterprise Server v2.1.1 Reference Manual.
-
Optionally, each server instance has access to the same high-availability database (HADB). HADB must be installed and the enterprise profile must be selected. For information about profiles, see Usage Profiles in Sun GlassFish Enterprise Server v2.1.1 Administration Guide. For information about HADB, see the description of the configure-ha-cluster command in the Sun GlassFish Enterprise Server v2.1.1 Reference Manual.
Note –
Contrary to the Servlet 2.5 specification, Enterprise 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 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 failover 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 Enterprise Server v2.1.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 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 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 |
- © 2010, Oracle Corporation and/or its affiliates