The WebLogic Server supports HTTP Servlets that are written to conform
to the JavaSoft Java Servlet API, which are the packages javax.servlet and javax.servlet.http, available from
JavaSoft.
Note: These classes are already included in the package in the weblogicaux.jar file.
To use HTTP servlets with the WebLogic Server, you may
register them as entries in the WebLogic Server's weblogic.properties file. Servlets
are registered with the weblogic.httpd.register property
in the properties file, and arguments and initialization parameters to
be passed to the servlet are registered with the the weblogic.httpd.initArgs property. Registered
servlets are loaded at startup.
WebLogic has special servlets that allow you to serve classes and other
kinds of files without registering them. The ServletServlet, for example, allows you to request
any servlet in the servlet classpath. For security reasons, we do not
suggest that you deploy a production server with the ServletServlet
enabled.
For more information on registering servlets, check the WebLogic
Administrator Guide Setting WebLogic
properties.
The standard approach to using HTTP servlets with the WebLogic Server is to
register them in the weblogic.properties file. However, the ServletServlet is a
special kind of HTTP servlet that allows you to invoke other HTTP servlets
that are not registered in the properties file. There is more about writing
servlets and the ServletServlet in the Developers Guide,
"Using WebLogic HTTP Servlets".
Included in the distribution is a servlet that does one thing: it
loads class files from the WebLogic classpath. This
allows you to use additional directories for your Java class files (like applets
and servlets) as long as you include them in the WebLogic classpath.
Prior to the introduction of the ClasspathServlet, users had to copy
all the WebLogic classes and all of their own classes into a
single directory tree, then use the base of that directory tree for
CODEBASE and register that directory with the FileServlet. Such a
method meant that you could not keep your classes separated from the
WebLogic classes, because the CODEBASE had to refer to a single
directory.
The ClasspathServlet adds another layer of indirection to how WebLogic
finds classes; with it, WebLogic searches its entire classpath to
find classes for a request. That means you can have multiple directory
structures with class files that are all equally accessible to WebLogic.
Place your applet class files in the WebLogic classpath, as you would for a
regular Java class file. The WebLogic classpath is specified on the command
line when you start the server with the weblogic.class.path property.
For example, the applet "myapplets.mypackage.OpenTheTour.class" might be
located on your WebLogic host in the directory c:\appletdir\myapplets\mypackage\OpenTheTour.class,
where the C:\appletdir is included in
the weblogic.class.path property.
Call the HTML file with the URL:
http://WebLogicURL:Port/open.html
Where WebLogicURL:Port is the
URL and port number of the WebLogic Server.
The classes for the applet will be loaded from the WebLogic Server's
classpath.
Proxying requests to another HTTP server
When you use the WebLogic Server as your primary webserver, you may also
want to configure WebLogic to pass on, or proxy, certain requests to a
secondary HTTP server, like Netscape or Microsoft. Any request that
the WebLogic Server cannot answer it passes on, as received, to the URL
registered as the proxy servlet. You can even proxy to another
webserver on a different machine.
To set up a proxy, you set two properties in the weblogic.properties file:
weblogic.httpd.register.proxy=weblogic.t3.srvr.HttpProxyServlet
weblogic.httpd.initArgs.proxy=redirectURL=otherURL
where otherURL is the URL of the server to which proxy requests
should be directed.
The HttpProxyServlet (provided as part of the distribution) takes an
HTTP request, redirects it to the proxy URL, and sends the response to
the client's browser back through the WebLogic Server.
If you have the registration for the proxy servlet set up as the value
for the default servlet (in this case, weblogic.httpd.defaultServlet=proxy) then any file for
which WebLogic cannot answer a request will be proxied to the other
server.
Here is a sample request and how it would be handled:
- On a WebLogic Server "toyboat.toybox.com," a request is received for
http://toyboat.toybox.com/Docs/SomeFile.html. That file
doesn't exist in any of the configured WebLogic Server's searchable
directories or document root.
- The WebLogic Server is configured to proxy unanswerable requests to
http://another.server.com with the property entry
weblogic.httpd.initArgs.proxy=redirectURL=http://another.server.com.
- The request is proxied as http://another.server.com/Docs/SomeFile.html.
Setting up dynamic page compilation
Dynamic page compilation allows you to embed Java into an HTML page to provide
dynamic content to your web pages. Of the existing alternative syntaxes
available, WebLogic supports both the JHTML and JSP (JavaServer Pages) standards.
WebLogic can automatically compile JHTML or JSP files into servlets and call
upon them to respond to HTTP requests. There is more on writing JHTML and JSP
in the Developers Guides, Using WebLogic
JHTML, and Using WebLogic JSP.
WebLogic uses special page-compile-servlets for compiling and delivering JHTML
and JSP pages. These page-compile-servlets are a standard part of the WebLogic
Server, but you must register them in the weblogic.properties file with the relevant file extension. When
a user requests a ".jhtml" or ".jsp" page, the registered servlet compiles the
page (if necessary) into an HTTP
servlet which is invoked to deliver the response to the browser.
For future servlet projects we recommend that you use JSP instead of JHTML.
Setting up JHTML
As of release WebLogic Server 4.5.1, we recommend that you use JSP for
future servlet projects instead of JHTML. These notes remain here for
completeness.
To serve JHTML files, you must register the PageCompileServlet and several
initArgs as illustrated below:
weblogic.httpd.register.*.jhtml=\
weblogic.servlet.jhtmlc.PageCompileServlet
weblogic.httpd.initArgs.*.jhtml=\
verbose=boolean, false by default,\
pageCheckSeconds=interval WebLogic checks for recompilation,\
compileCommand=path to compiler,\
workingDir=path to directory of compiled .jhtml files
You will need to set the initialization arguments to match your
own installed environment. For example, you need to identify the
absolute path to your Java compiler. You also need to specify the
directory where the compiled servlet classes will be placed.
weblogic.httpd.initArgs.*.jhtml=\
compileCommand=c:/java/bin/javac.exe,\
workingDir=c:/weblogic/myserver/pagecompileHome
There are more details on the registration in the configuration guide,
Setting WebLogic properties.
Setting up JSP
To serve JSP files, you must register the JSPServlet and several
initialization parameters as illustrated below:
weblogic.httpd.register.*.jsp=\
weblogic.servlet.jspc.JSPServlet
weblogic.httpd.initArgs.*.jsp=\
verbose=boolean, false by default,\
pageCheckSeconds=interval WebLogic checks for recompilation,\
compileCommand=path to compiler,\
workingDir=path to directory of compiled .jsp files
You will need to set the initialization arguments to match your
own installed environment. For example, you need to identify the
absolute path to your Java compiler. You also need to specify the
directory where the compiled servlet classes will be placed.
weblogic.httpd.initArgs.*.jsp=\
compileCommand=c:/java/java115/bin/javac.exe,\
workingDir=c:/weblogic/myserver/pagecompileHome
There are more details on configuring the WebLogic Server for JSP in the
Administrators Guide Setting WebLogic
Properties. For information on developing JSP, see the Developer Guide,
Using WebLogic JSP.
Using server-side includes
WebLogic provides limited server-side include functionality to support your
legacy SSI pages. For new projects, we suggest you use the include directive
in JavaServer Pages.
The WebLogic Server supports server-side includes using a standard WebLogic
servlet called the
ServerSideIncludeServlet. Traditionally, server side include pages have
the extension .shtml. The ServerSideIncludeServlet is registered in
the weblogic.properties file to handle
all .shtml files using this property:
weblogic.httpd.register.*.shtml=\
weblogic.servlet.ServerSideIncludeServlet
SHTML files must be located under the document
root, as is the case for static HTML pages.
There is more information about server-side includes in the Developers Guide,
Using WebLogic HTTP
Servlets.
Using legacy CGI
WebLogic provides functionality to support your legacy CGI scripts. For
new projects, we suggest you use HTTP servlets or JavaServer Pages.
The WebLogic Server supports all CGI scripts via a standard WebLogic
servlet called the CGIServlet. You
must register the CGIServlet in the
weblogic.properties file to handle
requests to specific URL patterns.
To enable traditional CGI in WebLogic Server, register the CGIServlet against the URL pattern cgi-bin as shown here:
weblogic.httpd.register.cgi-bin=weblogic.servlet.CGIServlet
weblogic.httpd.initArgs.cgi-bin=\
cgiDir=/weblogic/myserver/cgi-bin,\
*.pl=/bin/perl.exe,\
*.class=/java/java.exe
You must supply initialization arguments for the CGIServlet -- the second property shown above, where cgiDir specifies the directory where
your CGI scripts are located. You can specify multiple CGI directories
separated by a semi-colon (;) on NT, a colon (:) on UNIX, or the appropriate
file path separator for your operating system. If you do not
specify cgiDir, the property defaults
to a directory named cgi-bin under the
document root.
The other initialization arguments specify extension mappings. These map
HTTP requests for scripts with a specific extension to the appropriate
interpreter or executable that runs the script. The output from the executed
script provides the HTTP response. Your extension mappings must begin with an
asterisk followed by a dot. In the example above, all requested files ending
with *.pl should be located in the
directory given by cgiDir and are
interpreted by the /bin/perl.exe
executable.
If a script or executable does not require an interpreter, such as a shell
script or an .exe file on NT, then it
does not require an extension mapping. Simply place the script or executable
in one of the cgiDir directories, and
request it as you would any other CGI script.
The URL used to request a perl script must follow the pattern:
http://server:port/cgi-bin/myscript.pl
Where server:port is the address of
your WebLogic Server, cgi-bin is the
virtual name mapped to the CGIServlet,
and myscript.pl is the name of the
perl script that is located in the /weblogic/myserver/cgi-bin directory given by the cgiDir initArg.
Known limitations
- You cannot use relative URIs in your CGI scripts.
Setting standard MIME types
You will also configure your WebLogic Server to serve certain MIME types
by making a registration in the properties file, such as:
weblogic.httpd.mimeType.text/html=html,htm
weblogic.httpd.mimeType.image/gif=gif
weblogic.httpd.mimeType.image/jpeg=jpeg,jpg
weblogic.httpd.mimeType.application/pdf=pdf
weblogic.httpd.mimeType.application/zip=zip
weblogic.httpd.mimeType.application/x-java-vm=class
weblogic.httpd.mimeType.application/x-java-archive=jar
weblogic.httpd.mimeType.application/x-java-serialized-object=ser
There is more on this in the the configuration document,
Setting WebLogic properties.
Setting up the WebLogic Server for HTTP tunneling
HTTP tunneling provides a way to simulate a statefull socket connection
between the WebLogic Server and a Java client when your only option is to use
the HTTP protocol. It is generally used to 'tunnel' through an HTTP port in a
security firewall. HTTP is a stateless protocol, but WebLogic provides
tunneling functionality to make the connection appear to be a regular
T3Connection. However, you can expect some performance loss in comparison to a
normal socket connection.
Configuring HTTP Tunneling on the WebLogic Server
The WebLogic server is always set up to receive HTTP tunnel requests.
However, you must enable servlets in the weblogic.properties file, using the following setting:
weblogic.allow.execute.weblogic.servlet=everyone
WebLogic HTTP tunneling uses a number of internal servlets to handle the HTTP
tunnel requests. You can control access to other specific servlets with other
properties as described in
Setting up ACLs for servlets in the WebLogic realm.
You control access to services through an HTTP tunnel connection in the
same way as you control access to those services accessed via a regular
T3Connection.
Connecting from the client
When your client requests a connection with the WebLogic Server, all you need
to do in order to use HTTP tunneling is specify the HTTP protocol in the URL.
For instance:
Hashtable env = new Hashtable();
env.put(Context.PROVIDER_URL, "http://wlhost:80");
Context ctx = new InitialContext(env);
On the client side, a special tag is appended to the http protocol, so that the WebLogic Server knows this is a
tunneling connection, instead of a regular HTTP request. Your
application code does not need to do any extra work to make this happen.
The client must specify the port in the URL, even if the port is 80.
You can set up your WebLogic Server to listen for HTTP requests on any
port, although the most common choice is port 80 since requests to port
80 are customarily allowed through a firewall.
To specify the port for the WebLogic Server, set the property
weblogic.system.listenPort in the
weblogic.properties file.
Configuring the HTTP tunneling connection
Under the HTTP protocol, a client may only make a request, and then accept
a reply from a server. The server may not voluntarily communicate with the
client, and the protocol is stateless, meaning that a continuous two-way
connection is not possible.
WebLogic HTTP tunneling simulates a T3Connection via the HTTP protocol,
overcoming these limitations. There are two properties that you may configure
in the weblogic.properties file on the
server to tune a tunneled connection for performance. It is advised
that you leave them at their default settings unless you experience connection
problems. These properties are used by the server to determine that the client
connection is still valid, or that the client is still alive.
Here, we talk about the underlying WebLogic implementation of the
client-to-server HTTP tunneling connection. This is not behavior that an
application developer needs to implement, but we explain it here so that you
can understand these properties.
- weblogic.httpd.tunneling.clientPingSecs=xx
When an HTTP tunnel connection is setup, the client automatically
sends a request to the server, so that the server may volunteer a response to
the client. The client may also include instructions in a request, but this
behavior happens regardless of whether the client application needs to
communicate with the server. If the server does not purposefully respond to
the client request within
clientPingSecs seconds, it does so anyway. The client accepts the
response and automatically sends another request immediately.
Default is 45 seconds; valid range is 20 to 900 seconds.
- weblogic.httpd.tunneling.clientTimeoutSecs=xx
If clientTimeoutSecs seconds have
elapsed since the client last sent a request to the server (in response to a
reply), then the server regards the client as dead, and terminates the HTTP
tunnel connection. The server checks the elapsed time every clientPingSecs, when it would otherwise
respond to the client's request.
Default is 40 seconds; valid range is 10 to 900 seconds.
Setting up HTTP server log files
The WebLogic Server can keep a log of all HTTP transactions in a
text file in either common log format, or extended log format. Common log
format is the default, and follows a standard convention. Extended log format
allows you to customize the information that is recorded.
To enable logging, set the following property in you weblogic.properties file:
weblogic.httpd.enableLogFile=true
weblogic.httpd.logFileName=name_of_log_file
weblogic.httpd.logFileFormat=[common | extended]
weblogic.httpd.logFileFlushSecs=seconds
Where name_of_log_file is the
file where HTTP information is appended to. This defaults to
access.log
and is recorded under the myserver
directory in your WebLogic installation directory.
You may set the log format to either extended log format or common log
format. Both formats are described below.
Note: If you are testing the log format, you should set the
logFileFlushSecs
property to 1 second, so it is updated
frequently. Otherwise, the server may not flush the log file before you shut
down the server. The default value is 60 seconds, to improve performance. For a
production system, you should use the default or a higher value.
All regular WebLogic Server logs shall continue to be written to the weblogic.log file; only the subset of log
information related to HTTP access shall be written to the
access.log file.
Note that the HTTP log is always appended to, even between server down-time,
and so will grow indefinitely. You should maintain it manually.
Next, we'll discuss the two type of log format that the WebLogic Server
supports.
Using Common Log format
The default format for logged HTTP information is the common log format. This standard format follows the pattern:
host RFC931 auth_user
[day/month/year:hour:minute:second UTC_offset]
"request" status bytes
- host
- Either the DNS name or the IP number of the remote client
- RFC931
- Any information returned by IDENTD for the remote client;
WebLogic does not support user identification
- auth_user
- If remote client user sent a userid for authentication, the user name;
otherwise "-"
- day/month/year:hour:minute:second UTC_offset
- Day, calendar month, year and time of day (24-hour format)
with the hours difference between local time and GMT, enclose in
square brackets
- "request"
- First line of the HTTP request submitted by the remote client
enclosed in double quotes
- status
- HTTP status code returned by the server, if available;
otherwise "-"
- bytes
- Number of bytes listed as the content-length in the HTTP/1.0
header, not including the HTTP/1.0 header, if known; otherwise "-"
Using extended log file format
The WebLogic Server also supports the extended log file format, version
1.0, as defined by the W3C. This is an emerging standard, and WebLogic follows
the draft specification outlined at
www.w3.org/TR/WD-logfile.html. This URL may be subject to change, but
the current definitive reference may be found from the W3C page at www.w3.org/pub/WWW/TR.
The extended log format allows you to specify the type and order of
information recorded about each HTTP communication. To enable the extended log
format, set the following property in your weblogic.properties file, along with the other properties
described above:
weblogic.httpd.logFileFormat=extended
You specify what information should be recorded in the log file with
directives, included in the actual log file itself. A directive begins on a new
line and starts with a # sign. If the log file
does not exist, a new log file will be created with default directives.
However, if the log file does already exist when the server starts, it must
contain legal directives at the head of the file.
The first line of your log file must contain a directive stating the
version number of the log file format. You must also include
a Fields directive near the beginning
of the file:
#Version: 1.0
#Fields: xxxx xxxx xxxx ...
Where each xxxx describes the data
fields to be recorded. Field types are specified as either simple identifiers,
or may take a prefix-identifier format, as defined in the W3C specification.
Here is an example:
#Fields: date time cs-method cs-uri
This would instruct the server to record the date and time of the transaction,
the request method that the client used, and the URI of the request for each
HTTP access. Each field is separated by whitespace, and each record is written
to a new line, appended to the log file.
Note: The #Fields directive
must be followed by a new line in the log file, so that the first log message
is not appended to the same line.
Supported Field identifiers
The following identifiers are supported, and do not require a prefix.
- date
- Date at which transaction completed, field has type <date>, as defined in the W3C specification.
- time
- Time at which transaction completed, field has type <time>, as
defined in the W3C specification.
- time-taken
- Time taken for transaction to complete in seconds, field has type
<fixed>, as defined in the W3C specification.
- bytes
- Number of bytes transferred, field has type <integer>
Note that the cached field defined
in the W3C specification is not supported in the WebLogic Server.
The following identifiers require prefixes, and cannot be used alone. The
supported prefix combinations are explained individually.
- IP address related fields:
- These fields give the IP address and port of either the requesting
client, or the responding server. This field has type <address>, as
defined in the W3C specification. The supported prefixes are:
- c-ip
- The IP address of the client.
- s-ip
- The IP address of the server.
- DNS related fields
- These fields give the domain names of the client or the server. This
field has type <name>, as defined in the W3C specification. The
supported prefixes are:
- c-dns
- The domain name of the requesting client
- s-dns
- The domain name of the requested server
- sc-status
- Status code of the response, for example (404) indicating a "File not
found" status. This field has type <integer>, as defined in the W3C
specification.
- sc-comment
- The comment returned with status code, for instance "File not found".
This field has type <text>
- cs-method
- The request method, for example GET or POST. This field has type
<name>, as defined in the W3C specification.
- cs-uri
- The full requested URI. This field has type <uri>, as defined in
the W3C specification.
- cs-uri-stem
- Only the stem portion of URI (omitting query). This field has type
<uri>, as defined in the W3C specification.
- cs-uri-query
- Only the query portion of the URI. This field has type <uri>, as
defined in the W3C specification.
Enabling event-based HTTP request information
After release 2.5, you can also register an interest in HTTP requests
by registering at the topic WEBLOGIC.LOG.HTTPD. The ParamSet that is passed with
each EventMessage includes the following:
- REMOTE_HOST
- RFC931
- AUTH_USER
- DATE
- REQUEST
- STATUS
- BYTES
To enable this feature, you must:
- Set the property weblogic.httpd.enableEvents to
true in the
weblogic.properties file,
as detailed in the WebLogic Administrators Guide document,
Setting WebLogic properties.
- Start the WebLogic Server and register an interest in the event
WEBLOGIC.LOG.HTTPD.
Setting up session management
For an introduction to HTTP sessions, see the Developer's Guide,
Using session tracking from a servlet.
The WebLogic Server is set up to handle session tracking by default. You need
not set any of these properties to use session tracking, but
configuring how WebLogic manages sessions is a key part of tuning your
servlet application for best performance. This will depend upon factors such
as:
- How many users you expect to hit the servlet
- How many concurrent users hit the servlet
- How long each session will last
- How much data you expect to store for each user
HTTP session properties
You configure WebLogic's session tracking with properties in the weblogic.properties file. (A summary list of
all configuration properties are detailed in the WebLogic Administrators
Guide, Setting WebLogic
properties.) The relevant properties are described here in more detail:
- weblogic.httpd.session.enable=true
- By default, this property is set to true to enable session tracking using
the HttpSession object in the
WebLogic Server. You can disable session tracking by setting this property to
false.
- weblogic.httpd.session.timeoutSecs=x
- Sets how long WebLogic waits before timing out a session, where x is the
number of seconds between a session's activity. Sessions occupy RAM, and on
busy sites you can tune your application by adjusting the time-out of sessions
appropriately. While you want to give a browser client every opportunity to
finish a session, you do not want to tie up the Server needlessly if the user
has left the site or otherwise abandoned the session.(Defaults to 3600;
minimum is 1, maximum is Integer.MAX_VALUE.)
-
weblogic.httpd.session.invalidationIntervalSecs=x
- Where x sets how long WebLogic waits between doing
house-cleaning checks for timed out and invalid sessions, at which
point WebLogic will delete the old sessions and free up memory. Again,
this is a parameter you use to tune the server for best
performance on high traffic sites. If unset, the property defaults
to 60 seconds; the minimum is every second (1), and the maximum is
once a week (604,800 seconds).
Configuring session cookies
The WebLogic Server uses cookies for session management when supported
by the client browser.
The cookies that the WebLogic Server uses to track sessions are set as
transient by default and do not out-live the life of the browser. When
a user quits their browser, the cookies are lost and the session
lifetime is regarded as over. This behavior is in-the-spirit of
session usage and it is recommended that you use sessions in this way.
However, it is possible to configure
many aspects of the cookies used to track sessions with the
following properties in the weblogic.properties file.
- weblogic.httpd.session.cookies.enable=boolean
- Use of session cookies is enabled by default and is recommended,
but you can disable them by setting this property to false. You might turn
this option off to test URL rewriting on your site.
- weblogic.httpd.session.cookie.comment=cookieComment
- Sets the comment that is stored internally in the cookie. The user
does not usually see this, but it appears in the cookie file to identify
the cookie. This defaults to "WebLogic Session Tracking Cookie" if
unset. You can set it to a more appropriate name for your application.
- weblogic.httpd.session.cookie.domain
- This property identifies the server that the browser shall send
this cookie information to when the browser makes a request. This defaults
to the server that issued the cookie. For example,
.mydomain.com will send cookies back to any server in the
*.mydomain.com domain. The domain name must have at least two
parts; a name set to *.com or *.net is invalid. You will
normally leave this unset to use the default. However, you can set
this to a different server, causing the cookie to be sent there when
the user visits.
- weblogic.httpd.session.cookie.maxAgeSecs
- This property sets the lifespan of the cookie, where x is the number of
seconds that the cookie shall be valid before it expires on the client.
This defaults to "-1" if unset, which sets the cookie to expire when the user
exits the browser. The minimum value is 0, which means the cookie is cleaned
up immediately (hardly ever used). The maximum value is MAX_VALUE, which
means the cookie lasts essentially forever. It is recommended that you leave
this value as "-1" which is in-the-spirit of session tracking. That is, a
session should die when the user exits the browser.
For longer lived client-side user data, your application should create and
set it is own cookies on the browser via the HTTP servlet API, and should not
attempt to use the cookies associated with the HTTP session. Your application
might use cookies to auto-login a user from a particular machine, in which
case you would set a new cookie to last for a long time. Remember that the
cookie will only be sent from that client machine; Your application should
store data on the server if it must be accessed by the user from multiple
locations.
Note that you can't directly connect the age of a browser cookie with
the length of a session. If a cookie goes away before its associated
session, that session becomes orphaned. If a session goes away before
its associated cookie, the servlet will not be able to find a
session. At that point, a new session will be assigned when the getSession() method is called. You should
only make transient use of sessions.
- weblogic.httpd.session.cookie.name
- Defaults to "WebLogicSession" if unset. You may set this to a more
appropriate name for your application. When you are using in-memory replication, the session cookie name must be the same as the cookie name set in the NSAPI plugin using the parameter "CookieName". Cookie names have local scope to the
issuing domain, so there is no problem with conflicts between your server and
other servers. However, two or more applications that use session tracking and
run on the same server will use the same cookie, and hence share the
same session. This is one reason why sessions should be treated as transient
data stores.
- weblogic.httpd.session.cookie.path
- Defaults to "/" if unset, which means that the browser will send cookies
to all URLs served by the WebLogic Server. You can set the path to a narrower
mapping to limit the request URLs that the browser will send cookies to.
For more information on setting configuration properties, see the
WebLogic Administrators Guide, Setting WebLogic
properties.
Configuring session persistence
For an introduction to HTTP session persistence, see the Developers Guide,
Making sessions persistent.
There are four different implementations of session persistence:
- Memory (single-server, non-replicated)
- File system persistence
- JDBC persistence
- In-memory replication (across a cluster)
The first three are covered here; in-memory replication is covered in the Administrators Guide
Setting up a WebLogic Cluster: Using in-memory state replication with a proxy server.
For each method, you will need to specify the value of the property
weblogic.httpd.session.persistence.
For file, JDBC and in-memory replication, you will need to set additional properties,
including the
weblogic.httpd.session.persistentStoreType.
Each method has its own set of properties as shown below.
Common properties
You can configure the number of sessions that are held in RAM
by setting the following properties. These properties are only applicable if
you are using session persistence:
- weblogic.httpd.session.cacheEntries=x
- Where x
limits the number of cached sessions at any time.
If you are expecting high volumes of simultaneous active
sessions, you do not want these sessions to soak up the RAM of your
server since 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 1024. The minimum is 16, and maximum is
Integer.MAX_VALUE. An empty session
uses less than 100 bytes, but will grow as data is added to it.
- weblogic.httpd.session.swapIntervalSecs=x
- Where x is the interval the server waits between purging the least
recently used sessions from the cache to the persistent store, when the cacheEntries limit has been reached.
If unset, this property defaults to 10 seconds; minimum is 1 second, and
maximum is 604800 (1 week).
Using memory-based, single-server, non-replicated persistent storage
To use memory-based, single-server, non-replicated persistent storage,
set the property:
weblogic.httpd.session.persistence=false
Using file-based persistent storage
For file-based persistent storage for sessions:
- Set the session persistence to true:
weblogic.httpd.session.persistence=true
- Set file as the persistent store
method by setting the property:
weblogic.httpd.session.persistentStoreType=file
- Set the directory where WebLogic will store the sessions, using property:
weblogic.httpd.session.persistentStoreDir=dirPath
where dirPath is either a directory
relative to the myserver/
directory in your WebLogic installation or an absolute path. Ensure that you have enough
room on disk to store the number of valid sessions multiplied by the size of
each session.
You can make file-persistent sessions cluster-able
by making this directory a shared directory amongst different servers.
You will need to create this directory manually.
Using a database for persistent storage
For JDBC-based persistent storage for sessions:
- Set the session persistence to true:
weblogic.httpd.session.persistence=true
- Set jdbc as the persistent store
method by setting the property:
weblogic.httpd.session.persistentStoreType=jdbc
- Set a JDBC connection pool to be used for the persistence storage:
weblogic.httpd.session.persistentStorePool=virtualPoolName
Note: virtualPoolName must be a
JDBC connection pool that is only used by JTS pool drivers. In other
words, you cannot use a JDBC connection that is used by non-JTS drivers. To be
safe, you should create a separate JDBC pool for session persistence; but you
can share a JDBC pool that is used only for servlet session
persistence and/or EJB, since these use JTS pool drivers.
The JTS pool driver uses a JDBC pool to support special transactional
connections that do not operate in the same way as straight JDBC pool
connections. JTS transactions are used by EJB and by servlet persistence.
Regular JDBC connections use a weblogic.jdbc.pool.Driver class, but servlet persistence uses a
proxy weblogic.jts.pool.Driver class.
Although you set up both types of pools with the same property name
(weblogic.jdbc.connectionPool),
you can't mix JTS and regular traffic in the same connection.
For more details on setting up a database connection pool, refer to Setting up registration for a connection pool
later in this document, and the JDBC connection
pools section in the Administrators Guide document,
Setting WebLogic properties.
To recap, you might use a non-JTS connection pool in
your servlet for general database access, but you can not use
the same connection pool to support session persistence.
- Set an ACL for the connection pool that corresponds to the users
that have permission.
- Set this property to the name of the connection pool.
- If the back-end database will be used by multiple WebLogic Servers
for JDBC-based persistence, set the property:
weblogic.httpd.session.persistentStoreShared=true
This property refers to whether database reads are cached. Generally, clustered environments will want
persistentStoreShared=true, that is always check the
database, but for non-clustered environments using
persistentStoreShared=false improves performance with
caching.
- Set up a database table named wl_servlet_sessions for JDBC-based
persistence. The connection pool that connects
to the database will need to have read/write access for this
table:
wl_servlet_sessions table
| Column name |
Type |
| wl_id |
Must be set as a primary key. Variable-width
alphanumeric column, up to 100 characters;
for example, Oracle VARCHAR2(100) |
| wl_is_new |
Single char column; for example, Oracle CHAR(1)
|
| wl_create_time |
Numeric column, 20 digits; for example,
Oracle NUMBER(20) |
| wl_is_valid |
Single char column; for example, Oracle CHAR(1)
|
| wl_session_values |
BLOB column; for example, Oracle LONG RAW |
| wl_access_time |
Numeric column, 20 digits; for example, NUMBER(20) |
- You can configure a maximum duration that the JDBC session persistence should
wait for a JDBC connection from the connection pool before failing to load the
session data wit the property:
weblogic.httpd.session.jdbc.connTimeoutSec=x
where x is the number of seconds that
the servlet will wait for a connection. The default value is 120 seconds, the
minimum is 1 second, and the maximum is 604800 seconds (1 week).
