This section covers the following topics:
Make sure that multiple threads don’t simultaneously modify the same session object in conflicting ways.
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.
Whenever a redeployment is done, the sessions at that transit time become invalid unless you use the keepSessions=true property of the asadmin redeploy command. For example:
asadmin redeploy --properties keepSessions=true --name hello.war
For details, see the Oracle GlassFish Server 3.0.1 Reference Manual.
The new class loader of the redeployed application is used to deserialize any sessions previously saved. The usual restrictions about serialization and deserialization apply. For example, any application-specific class referenced by a session attribute may evolve only in a backward-compatible fashion. For more information about class loaders, see Chapter 2, Class Loaders.
You can write session attribute values to an access log. The access log format token %session.name% logs one of the following:
The value of the session attribute with the name name
NULL-SESSION-ATTRIBUTE-name if the named attribute does not exist in the session
NULL-SESSION if no session exists
For more information about access logging and format tokens, see online help for the Access Log tab of the HTTP Service page in the Administration Console.