Using Sessions and Session Persistence 10-7
If you are using DB2, use the following SQL statement to create the wl_servlet_ sessions table. Modify the SQL statement for use with your DBMS.
Example 10–3 Creating wl_servlet_sessions table with DB2
CREATE TABLE WL_SERVLET_SESSIONS WL_ID VARCHAR100 not null,
WL_CONTEXT_PATH VARCHAR100 not null, WL_IS_NEW SMALLINT,
WL_CREATE_TIME DECIMAL16, WL_IS_VALID SMALLINT,
wl_session_values BLOB10M NOT LOGGED, WL_ACCESS_TIME DECIMAL16,
WL_MAX_INACTIVE_INTERVAL INTEGER, PRIMARY KEY WL_ID,WL_CONTEXT_PATH
;
If you are using Sybase, use the following SQL statement to create the wl_servlet_ sessions table. Modify the SQL statement for use with your DBMS.
Example 10–4 Creating wl_servlet_sessions table with Sybase
create table WL_SERVLET_SESSIONS WL_ID varchar100 not null ,
WL_CONTEXT_PATH varchar100 not null , WL_IS_NEW smallint null ,
WL_CREATE_TIME decimal16,0 null , WL_IS_VALID smallint null ,
WL_SESSION_VALUES image null , WL_ACCESS_TIME decimal16,0 null ,
WL_MAX_INACTIVE_INTERVAL int null , go
alter table WL_SERVLET_SESSIONS add PRIMARY KEY CLUSTERED WL_ID, WL_CONTEXT_PATH
go
10.4.2 Caching and Database Updates for JDBC Session Persistence
WebLogic Server does not write the HTTP session state to disk if the request is read-only, meaning the request does not modify the HTTP session. Only the wl_
access_time column is updated in the database, if the session is accessed.
For non read-only requests, the Web application container updates the database for the changes to session state after every HTTP request. This is done so that any server in
the cluster can handle requests upon failovers and retrieve the latest session state from the database.
To prevent multiple database queries, WebLogic Server caches recently used sessions. Recently used sessions are not refreshed from the database for every request. The
number of sessions in cache is governed by the cache-size parameter in the session-descriptor element of the WebLogic Server-specific deployment
descriptor, weblogic.xml. See
Section B.10, session-descriptor .
10-8 Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server
10.4.3 Using Cookie-Based Session Persistence
Cookie-based session persistence provides a stateless solution for session persistence by storing all session data in a cookie in the users 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.
There are some limitations to cookie-based session persistence:
■
You can store only string attributes in the session. If you store any other type of object in the session, an IllegalArgument exception is thrown.
■
You cannot flush the HTTP response because the cookie must be written to the header data before the response is committed.
■
If the content length of the response exceeds the buffer size, the response is automatically flushed and the session data cannot be updated in the cookie. The
buffer size is, by default, 8192 bytes. You can change the buffer size with the javax.servlet.ServletResponse.setBufferSize method.
■
You can only use basic browser-based authentication.
■
Session data is sent to the browser in clear text.
■
The users browser must be configured to accept cookies.
■
You cannot use commas , in a string when using cookie-based session persistence or an exception occurs.
To set up cookie-based session persistence:
■
Set the persistent-store-type parameter in the session-descriptor element in the weblogic.xml deployment descriptor file to cookie. See
Section B.10, session-descriptor .
■
Optionally, set a name for the cookie using the persistent-store-cookie-name element. The default is WLCOOKIE. See
Section B.10, session-descriptor .
10.5 Using URL Rewriting Instead of Cookies
