Using Sessions and Session Persistence 10-15
WebLogic Server uses URL rewriting when a session is new, even if the browser accepts cookies, because the server cannot determine, during the first visit of a session,
whether the browser accepts cookies.
Your servlet may determine whether a given session was returned from a cookie by checking the Boolean returned from the
HttpServletRequest.isRequestedSessionIdFromCookie method. Your application may respond appropriately, or it may simply rely on URL rewriting by
WebLogic Server.
10.6.10 URL Rewriting and Wireless Access Protocol WAP
If you are writing a WAP application, you must use URL rewriting because the WAP protocol does not support cookies. In addition, some WAP devices impose a
128-character limit including parameters on the length of a URL, which limits the amount of data that can be transmitted using URL rewriting. To allow more space for
parameters, you can limit the size of the session ID that is randomly generated by WebLogic Server by specifying the number of bytes with the id-length parameter in
the session-descriptor element of the WebLogic Server-specific deployment descriptor, weblogic.xml. See
Section B.10, session-descriptor .
The minimum value is 8 bytes; the default value is 52 bytes; the maximum value is Integer.MAX_VALUE.
10.6.11 Making Sessions Persistent
You can set up WebLogic Server to record session data in a persistent store. If you are using session persistence, you can expect the following characteristics:
■
Good failover, because sessions are saved when servers fail.
■
Better load balancing, because any server can handle requests for any number of sessions, and use caching to optimize performance. For more information, see the
cache-size property, at Section 10.3, Configuring Session Persistence
.
■
Sessions can be shared across clustered WebLogic Servers. Note that session persistence is no longer a requirement in a WebLogic Cluster. Instead, you can use
in-memory replication of state. For more information, see Using Clusters for Oracle WebLogic Server.
■
For customers who want the highest in servlet session persistence, JDBC-based persistence is the best choice. For customers who want to sacrifice some amount of
session persistence in favor of drastically better performance, in-memory replication is the appropriate choice. JDBC-based persistence is noticeably slower
than in-memory replication. In some cases, in-memory replication has outperformed JDBC-based persistence for servlet sessions by a factor of eight.
■
You can put any kind of Java object into a session, but for file, JDBC, and in-memory replication, only objects that are java.io.Serializable can be
stored in a session. For more information, see Section 10.3, Configuring Session
Persistence .
Note: The CISCO Local Director load balancer expects a question
mark ? delimiter for URL rewriting. Because the WebLogic Server URL-rewriting mechanism uses a semicolon ; as the delimiter, our
URL rewriting is incompatible with this load balancer.
10-16 Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server
10.6.11.1 Scenarios to Avoid When Using Sessions
Do not use session persistence for storing long-term data between sessions. In other words, do not rely on a session still being active when a client returns to a site at some
later date. Instead, your application should record long-term or important information in a database.
Sessions are not a convenience wrapper around cookies. Do not attempt to store long-term or limited-term client data in a session. Instead, your application should
create and set its own cookies on the browser. Examples include an auto-login feature that allows a cookie to live for a long period, or an auto-logout feature that allows a
cookie to expire after a short period of time. Here, you should not attempt to use HTTP sessions. Instead, you should write your own application-specific logic.
10.6.11.2 Use Serializable Attribute Values
When you use persistent sessions, all attribute value objects that you add to the session must implement java.io.Serializable.
If you add your own serializable classes to a persistent session, make sure that each instance variable of your class is also serializable. Otherwise, you can declare it as
transient, and WebLogic Server does not attempt to save that variable to persistent storage. One common example of an instance variable that must be made transient
is the HttpSession object. See the notes on using serialized objects in sessions in the section
Section 10.6.11, Making Sessions Persistent .
The HttpServletRequest, ServletContext, and HttpSession attributes will be serialized when a WebLogic Server instance detects a change in the Web application
classloader. The classloader changes when a Web application is redeployed, when there is a dynamic change in a servlet, or when there is a cross Web application
forward or include.
To avoid having the attribute serialized, during a dynamic change in a servlet, turn off servlet-reload-check-secs in weblogic.xml. There is no way to avoid
serialization of attributes for cross Web application dispatch or redeployment. See Section B.13.6, servlet-reload-check-secs
.
10.6.11.3 Configuring Session Persistence
For details about setting up persistent sessions, see Section 10.3, Configuring Session
Persistence .
10.6.12 Configuring a Maximum Limit on In-memory Servlet Sessions
Without the ability to configure in-memory servlet session use, as new sessions are continually created, the server eventually throws out of memory. To protect against
this, WebLogic Server provides a configurable bound on the number of sessions created. When this number is exceeded, the
weblogic.servlet.SessionCreationException occurs for each attempt to create a new session. This feature applies to both replicated and non-replicated
in-memory sessions.
To configure bound in-memory servlet session use, you set the limitation in the max-in-memory-sessions element in the weblogic.xml deployment descriptor.
See Section B.10, session-descriptor
.
Using Sessions and Session Persistence 10-17
10.6.13 Enabling Session Memory Overload Protection
When memory is overloaded, a weblogic.servlet.SessionCreationException RuntimeException for
any getSessiontrue attempts occurs. As the person developing the servlet, you should handle this exception as follows:
■
Return the appropriate error message to the user when the exception occurs, explaining the situation.
■
Map weblogic.servlet.SessionCreationException to an error page in the J2EE standard Web application deployment descriptor, web.xml.
By default, memory overload protection is turned off. You can enable it with a domain-level flag:
weblogic.management.configuration.WebAppContainerMBean.OverloadProtectionEnabled
10-18 Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server
11
Application Events and Event Listener Classes 11-1
11
Application Events and Event Listener Classes
The following sections discuss application events and event listener classes:
■
Section 11.1, Overview of Application Event Listener Classes
■
Section 11.2, Servlet Context Events
■
Section 11.3, HTTP Session Events
■
Section 11.4, Servlet Request Events
■
Section 11.5, Configuring an Event Listener Class
■
Section 11.6, Writing an Event Listener Class
■
Section 11.7, Templates for Event Listener Classes
■
Section 11.8, Additional Resources
11.1 Overview of Application Event Listener Classes
Application events provide notifications of a change in state of the servlet context each Web application uses its own servlet context or of an HTTP session object. You write
event listener classes that respond to these changes in state, and you configure and deploy them in a Web application. The servlet container generates events that cause
the event listener classes to do something. In other words, the servlet container calls the methods on a users event listener class.
The following is an overview of this process:
1.
The user creates an event listener class that implements one of the listener interfaces.
2.
This implementation is registered in the deployment descriptor.
3.
At deployment time, the servlet container constructs an instance of the event listener class. This is why the public constructor must exist, as discussed in
Section 11.6, Writing an Event Listener Class .
4.
At run time, the servlet container invokes on the instance of the listener class. For servlet context events, the event listener classes can receive notification when the
Web application is deployed or undeployed or when WebLogic Server shuts down, and when attributes are added, removed, or replaced.
For HTTP session events, the event listener classes can receive notification when an HTTP session is activated or is about to be passivated, and when an HTTP session
attribute is added, removed, or replaced.
