Developing Web Applications for WebLogic Server
Session tracking enables you to track a user's progress over multiple servlets or HTML pages, which, by nature, are stateless. A session is defined as a series of related browser requests that come from the same client during a certain time period. Session tracking ties together a series of browser requests—think of these requests as pages—that may have some meaning as a whole, such as a shopping cart application.
WebLogic Server is set up to handle session tracking by default. You need not set any of these properties to use session tracking. However, configuring how WebLogic Server manages sessions is a key part of tuning your application for best performance. When you set up session management, you determine factors such as:
You can also store data permanently from an HTTP session. See Configuring Session Persistence.
You configure WebLogic Server session tracking by defining properties in the WebLogic-specific deployment descriptor,
weblogic.xml. For a complete list of session attributes, see session-descriptor.
A new server startup flag, -Dweblogic.servlet.useExtendedSessionFormat=true , retains the information that the load-balancing application needs for session stickiness. The extended session ID format will be part of the URL if URL rewriting is activated, and the startup flag is set to true.
TimeoutSecsattribute in the session-descriptor element of the WebLogic-specific deployment descriptor,
weblogic.xml.This value is set in seconds. For more information, see session-descriptor.
web.xml. For more information, see session-config.
The cookies that WebLogic Server uses to track sessions are set as transient by default and do not outlive the session. When a user quits the browser, the cookies are lost and the session ends. This behavior is in the spirit of session usage and it is recommended that you use sessions in this way.
You can configure session-tracking attributes of cookies in the WebLogic-specific deployment descriptor,
weblogic.xml. A complete list of session and cookie-related attributes is available in session-descriptor.
You cannot directly connect the age of a browser cookie with the length of a session. If a cookie expires before its associated session, that session becomes orphaned. If a session expires before its associated cookie, the servlet is not be able to find a session. At that point, a new session is automatically assigned when the
request.getSession(true) method is called.
User authentication information is stored both in the user's session data and in the context of a server or virtual host that is targeted by a Web application. The
session.invalidate() method, which is often used to log out a user, only invalidates the current session for a user—the user's authentication information still remains valid and is stored in the context of the server or virtual host. If the server or virtual host is hosting only one Web application, the
session.invalidate() method, in effect, logs out the user.
There are several Java methods and strategies you can use when using authentication with multiple Web applications. For more information, see Implementing Single Sign-On in Programming WebLogic HTTP Servlets.
You use session persistence to permanently store data from an HTTP session object to enable failover and load balancing across a cluster of WebLogic Servers. When your applications stores data in an HTTP session object, the data must be serializable.
File, JDBC, cookie-based, and memory (single-server, non-populated) session persistence have some common properties. Each persistence method has its own set of attributes, as discussed in the following sections. These attributes are part of the session-param element, which is a child element of the session-descriptor element in the weblogic.xml deployment descriptor file.
This section describes attributes common to file and JDBC-based persistence. You can configure the number of sessions that are held in memory by defining the following attributes in the
<session-param> element of the WebLogic-specific deployment descriptor,
weblogic.xml. These properties are only applicable if you are using session persistence:
Limits the number of cached sessions that can be active in memory at any one time. If you expect high volumes of simultaneous active sessions, you do not want these sessions to soak up the RAM of your server because this may cause performance problems swapping to and from virtual memory. When the cache is full, the least recently used sessions are stored in the persistent store and recalled automatically when required. If you do not use persistence, this property is ignored, and there is no soft limit to the number of sessions allowed in main memory. By default, the number of cached sessions is 256. To turn off caching, set this to 0.
Sets the time, in seconds, that WebLogic Server waits between doing house-cleaning checks for timed-out and invalid sessions, and deleting the old sessions and freeing up memory. Set this attribute to a value less than the value set for the
<session-timeout> element. Use this attribute to tune WebLogic Server for best performance on high traffic sites.
<session-timeout>, see session-config.
When you use memory-based storage, all session information is stored in memory and is lost when you stop and restart WebLogic Server. To use memory-based, single-server, non-replicated persistent storage, set the
PersistentStoreType attribute in the
<session-param> element of
weblogic.xml file to memory.
weblogic.xml, set the
PersistentStoreTypeattribute in the
JDBC persistence stores session data in a database table using a schema provided for this purpose. You can use any database for which you have a JDBC driver. You configure database access by using connection pools.
Because WebLogic Server uses the system time to determine the session lifetime when using JDBC session persistence, you must be sure to synchronize the system clock on all of the machines on which servers are running in the same cluster.
PersistentStorePoolproperty in the
<session-descriptor>element of the WebLogic-specific deployment descriptor,
weblogic.xml. Use the name of a connection pool that is defined in the WebLogic Server Administration Console.
wl_servlet_sessionsfor JDBC-based persistence. The connection pool that connects to the database needs to have read/write access for this table.
create table wl_servlet_sessions
( wl_id VARCHAR2(100) NOT NULL,
wl_context_path VARCHAR2(100) NOT NULL,
wl_session_values LONG RAW,
PRIMARY KEY (wl_id, wl_context_path) );
Note: You can use the
JDBCConnectionTimeoutSecs attribute to configure a maximum duration that JDBC session persistence should wait for a JDBC connection from the connection pool before failing to load the session data. For more information, see JDBCConnectionTimeoutSecs.
If you are using Pointbase, Pointbase translates the SQL. For example, Pointbase would translate the SQL provided in Listing 4-1 as follows.
Cookie-based session persistence provides a stateless solution for session persistence by storing all session data in a cookie in the user's browser. Cookie-based session persistence is most useful when you do not need to store large amounts of data in the session. Cookie-based session persistence can make managing your WebLogic Server installation easier because clustering failover logic is not required. Because the session is stored in the browser, not on the server, you can start and stop WebLogic Servers without losing sessions.
IllegalArgumentexception is thrown.
In some situations, a browser or wireless device may not accept cookies, which makes session tracking with cookies impossible. URL rewriting is a solution to this situation that can be substituted automatically when WebLogic Server detects that the browser does not accept cookies. URL rewriting involves encoding the session ID into the hyper-links on the Web pages that your servlet sends back to the browser. When the user subsequently clicks these links, WebLogic Server extracts the ID from the URL address and finds the appropriate
HttpSession when your servlet calls the
Enable URL rewriting in WebLogic Server by setting the
URLRewritingEnabled attribute in the WebLogic-specific deployment descriptor,
weblogic.xml, under the
true. See URLRewritingEnabled.
encodeURL() method determines whether the URL needs to be rewritten. If it does need to be rewritten, WebLogic Server rewrites the URL by appending the session ID to the URL, with the session ID preceded by a semicolon.
HttpServletRequest.isRequestedSessionIdFromCookie()method. Your application may respond appropriately, or simply rely on URL rewriting by WebLogic Server.
In addition, some WAP devices have a 128-character limit on the length of a URL (including attributes), which limits the amount of data that can be transmitted using URL rewriting. To allow more space for attributes, you can limit the size of the session ID that is randomly generated by WebLogic Server.
In particular, to use the
WAPEnabled attribute, use the Administration Console at Server
WAPEnabled attribute restricts the size of the session ID to 52 characters and disallows special characters, such as ! and #. You can also use the IDLength parameter of weblogic.xml to further restrict the size of the session ID. For additional details, see IDLength.