You can access session pools through the SessionPoolManager class. WebLogic Server uses a variation of the session pool called a servlet session pool. The servlet session pool provides extra functionality that is convenient for use inside an HTTP servlet.
When WebLogic is started (or restarted), it invokes the PoolManagerStartUp class and its associated
startupArgs. On the first invocation, the
PoolManagerStartUp class creates a
ServletSessionPoolManager object, which contains every
ServletSessionPool configured in the
config.xml configuration file.
Subsequent calls add another ServletSessionPool to the same
ServletSessionPoolManager. You must add an entry for each session pool, using a unique virtual name binding for each, as shown in the preceding example. The WebLogic Server creates a new
ServletSessionPool as defined in the
config.xml file.
The WebLogic Server uses a ServletSessionPoolManager class that is derived from
SessionPoolManager. The
ServletSessionPoolManager manages
ServletSessionPool objects, which offer additional HTTP servlet methods.
SessionPoolManager provides several methods for managing the administration of a session pool. In the following example, the
SessionPoolManager is used to retrieve the
SessionPool that has been named
joltpoolname:
You must cast the SessionPool to a
ServletSessionPool, as in the following code example:
Because WebLogic Server creates and configures the ServletSessionPoolManager, it is likely that this is the only method you will use. Other
SessionPoolManager methods allow you to create, suspend, stop, or shut down individual or all the session pools it manages. We recommend that you leave these administrative operations to the WebLogic Server by configuring and managing your session pools using the WebLogic
config.xml configuration file.
The reference to the named ServletSessionPool from the pool manager represents a pool of sessions (or connections) to the Jolt Server in Tuxedo. The size of this pool and the Tuxedo system to which it connects are abstracted from the application code and are defined in the WebLogic
config.xml configuration file. When you initiate a request, the
SessionPool uses the least-busy connection available.
A Jolt request usually consists of a single call to a Tuxedo service using the call() method of the
SessionPool. You supply the name of the Tuxedo service and a set of parameters to the
call() method, and it returns a set of results from the Tuxedo service. It is possible to make multiple calls within a single transaction, which allows a servlet to comply with transactional demands of a Tuxedo application or preserve integrity between databases. This transaction is described in more detail in “Using a Transaction” on page 3-9.
The ServletSessionPool provides overloaded
call() methods for use inside an HTTP servlet. These methods accept their input parameters in terms of an
HttpServletRequest object, and therefore can conveniently be passed the same
HttpServletRequest object that was passed into your HTTP servlet's
doPost() or
doGet() methods. However, in this instance, you must ensure that the names of the HTTP posted
name=value pairs correspond to those expected by the Tuxedo service. The ordering is not important, because the data is ultimately converted into a Java Hashtable. Other non-related data in the
HttpServletRequest will not disrupt the Tuxedo service.
ssPool.call("serviceName",
request);
where ssPool is a reference to a
ServletSessionPool,
"serviceName" is the name of the Tuxedo service you wish to call, and the
request argument is the
HttpServletRequest object associated with the servlet.
The ServletSessionPool.call() method internally converts the
HttpServletRequest into a
ServletDataSet, which can be submitted to a regular
SessionPool.
This code example demonstrates the manual conversion of the HttpServletRequest object into a
ServletDataSet object. In this new format you can add extra parameters using the
setValue() method. The new value is associated with a key, represented by a string. Next, the
call() method that is inherited from the
SessionPool is invoked. This method accepts the
ServletDataSet class, but requires an extra argument for use with transactions. Supply
null for this last parameter, indicating that you are not using a transaction to group multiple session calls. See
“Using a Transaction” on page 3‑8 for more details.
This feature is also used to convert all data inside an HttpServletRequest object, because all parameters associated with the request are represented in string format. Otherwise, use the type specified in the table below. Providing the correct data type may improve efficiency because no lookup is required to convert from a string.
A Tuxedo CARRAY is specified in a Java string by describing each byte value as a two-digit hexadecimal number. You specify multiple bytes by concatenating these hexadecimal digit-pairs together. For example, the string "
FF0A20" would represent the Tuxedo type
CARRAY { 255, 10, 32 }.
The ServletSessionPool.call() method returns a
ServletResult object that contains the results from the Tuxedo service. If the service call fails, an exception is thrown. You should always attempt to catch exceptions and handle them appropriately. Refer to “Appendix A, Oracle Jolt Exceptions” in
Using Oracle Jolt for details about the possible exceptions that can occur.
where ssPool is a
ServletSessionPool, and
request is an
HttpServletRequest.
The ServletSessionPool.call() method returns a
Result object that you must cast as a
ServletResult object. The
ServletResult object provides extra methods for retrieving data as Java Strings.
The data is retrieved from a ServletResult by providing a key that corresponds to the parameter names of the Tuxedo service, as defined in the Metadata Repository. You supply the key to the appropriate
getValue() method, which returns the corresponding value object.
The Result.getValue() method also expects a default value object; this is returned if the key lookup fails. It is your responsibility to cast the returned object to the appropriate type, as defined by the Tuxedo service. For example, this line of code:
ServletResult extends
Result, and provides the additional methods:
where the transaction object trans holds the reference to the transaction,
ssPool is the SessionPool or ServletSessionPool object, and the
timeout argument for the transaction is specified in seconds.
A JoltException is the super class of all the following exceptions. These exceptions all signify that a system error has occurred that is not part of the application logic.
JoltException is documented in Appendix A, “Oracle Jolt Exceptions,” in the
Using Oracle Jolt.