test

Sun Java System Application Server Enterprise Edition 8.2 Developer's Guide

Configuring Sessions

This section covers the following topics:

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.2 Administration Guide and the Sun Java System Application Server Enterprise Edition 8.2 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:

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:

For information about how to work around these limitations, see the Sun Java System Application Server Enterprise Edition 8.2 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