Configuring Jolt for WebLogic Server

Configuring a Jolt Session Pool connection between Tuxedo and WebLogic Server requires two procedures:

•	Configuring Jolt for Tuxedo

•	Configuring Jolt for WebLogic Server

Configuring Jolt for Tuxedo

Refer to the Using Oracle Jolt for instructions on setting up a Jolt Service Listener (JSL) within Tuxedo. In Using Oracle Jolt, it is assumed that JSL services have already been configured within the Tuxedo domain. The guide only describes how to establish a session pool connection to these services from WebLogic Server.

Configuring Jolt for WebLogic Server

This section describes how to set up an Oracle Jolt connection pool between the WebLogic Server and the JSL in the Tuxedo domain. Your WebLogic Server must have access to the host running the JSL.

Jolt Startup Class and Connection Pool

You must instruct WebLogic Server to invoke the PoolManagerStartUp class whenever the WebLogic Server is started or restarted. This invocation establishes the pool connection to Tuxedo from the config.xml file, as shown in the following example.

Note:

For WebLogic Server 6.0 or later, Jolt startup classes and connection pool attributes are configured via the configuration MBeans in the Administration Console. For more information about configuration and run-time MBeans, refer to the Oracle WebLogic Server Administration Guide.

<StartupClass
ClassName="bea.jolt.pool.servlet.weblogic.PoolManagerStartUp"
FailureIsFatal="false"
Name="MyStartup Class"
Targets="myserver"
/>
<JoltConnectionPool
ApplicationPassword="tuxedo"
MaximumPoolSize="5"
MinimumPoolSize="3"
Name="MyJolt Connection Pool"
PrimaryAddresses="//TUXSERVER:6309"
RecvTimeout="300"
SecurityContextEnabled="true"
Targets="myserver"
UserName="joltuser"
UserPassword="jolttest"
UserRole="clt"
/>

The startup class in the preceeding example instructs WebLogic Server to invoke the PoolManagerStartUp class when the WebLogic Server starts. The JoltConnectionPool specifies initialization arguments that are passed to the PoolManagerStartUp class. If you do not want the SessionPool to try to reestablish the connection in case any of the JSL is forced to shutdown, set the JVM property jolt.sessionPoolKeepAlive=false when starting up the Weblogic Server.

Jolt Connection Pool Attributes

The Jolt connection pool attributes are defined as follows:

 

Application Password	(Optional) Tuxedo application password. This is required only if the Tuxedo authentication level is USER_AUTH or APP_PW.
MininumPoolSize	(Required) Specifies the initial session pool size when the session pool is created.
MaximumPoolSize	(Required) Specifies the maximum session pool size. Each session within a pool can handle up to 50 outstanding requests at any one time.
Name	(Optional) Defines a name for this session pool that should be unique from the names of other session pools. This is an optional argument, but it is recommended that you use it to avoid ambiguity. The SessionPoolManager allows only one session pool to remain unnamed. You can access this unnamed session pool from your application by supplying null in place of the poolname string argument to the getSessionPool() method. Note: We strongly recommend that you name every session pool.
PrimaryAdresses	(Required) Defines a list of the addresses of the primary Jolt Server Listeners (JSLs) on the Tuxedo system. These are defined in the format: //hostname:port where hostname is the name of the server where the JSL is running, and port is the port on which the JSL is configured to listen for requests. You can specify multiple addresses in a semicolon-separated (;) list. Note: You must specify at least one primary JSL hostname:port address.
Failover Addresses	(Optional) You can specify a list of failover Jolt Server Listeners in the same format used for appaddrlist above. Jolt attempts to use these failover JSL(s) if the primary JSLs listed above fail. These JSLs need not reside on the same host as the primary JSLs.
RecvTimeout	(Required) Specifies the amount of time the client should wait to receive a response before timing out.
SecurityContextEnabled	(Optional) Enables or disables the security context for this connection pool. This option should be enabled if you want to implement authentication propagation between WebLogic Server and Jolt. If identity propagation is desired, then the Jolt Service Handler (JSH) must be started with the -a option. If this option is not set, but SecurityContext is enabled, the JSH will not accept this request. If the SecurityContext attribute is enabled, then the Jolt client will pass the username of the caller to the JSH. If the JSH gets a message with the caller’s identity, it calls impersonate_user() to get the appkey for the user. JSH caches the appkey, so the next time the caller makes a request, the appkey is retrieved from the cache and the request is forwarded to the service. A cache is maintained by each JSH, which means that there will be a cache maintained for all the session pools connected to the same JSH.
Targets	(Required) Specifies the target servers for the connection pool.
UserName	(Optional) Tuxedo user name. This is required only if the Tuxedo authentication level is USER_AUTH.
UserPassword	(Optional) Tuxedo user password. This is required only if the Tuxedo authentication level is USER_AUTH.
UserRole	(Optional) Tuxedo user role. This is required only if the Tuxedo authentication level is USER_AUTH or APP_PW.

It is recommended that you configure one Jolt session pool for each application running on the WebLogic Server.

Jolt Shutdown Class

To configure WebLogic Server to disconnect the Jolt session pools from Tuxedo when it shuts down, add the following lines to the WebLogic Server config.xml file:

<ShutdownClass
ClassName=”bea.jolt.pool.servlet.weblogic.PoolManager ShutDown.”
/>

The shutdown class instructs WebLogic Server to invoke the PoolManagerShutDown class when the WebLogic Server shuts down.

Displaying Jolt in the WebLogic Administration Console

If you are connecting to a WebLogic Server that has Jolt correctly installed and configured, when you start the Administration Console you will see a configuration MBean for the Jolt connection pool displayed in the Administration Console, as shown in Figure 2‑1.

Figure 2‑1 WebLogic Server Console with Jolt Connection Pool

For each Jolt connection pool there is an individual MBean that displays the pool name, maximum connections, pool state, and statistics about the connection status.

Note:

For more information about MBeans, refer to the Oracle WebLogic Server Administration Guide.

Resetting the Jolt Connection Pool

You can reset the Jolt connection pool without having to restart WebLogic Server. The resetConnectionPool() method calls the SessionPoolManager.stopSessionPool() method to shut down all the connections in the pool. It then calls the SessionPoolManager.createSessionPool() method to restart the connection pool.

Command-line Method

The resetConnectionPool method can be invoked from the Administration Console command-line interface by using the following command:

java weblogic.Admin -url t3://localhost:7001 -username system -password gumby1234 -invoke -mbean mydomain:Name=myserver.jolt.demojoltpool,Type=JoltConnectionPoolRuntime,Location=myserver -method resetConnectionPool

Administration Console Method

The Jolt connection pool can also be reset from the GUI console by using the following method:

1.	In the Administration Console, expand Interoperability and select Jolt Connection Pools.

2.	On the Jolt Connection Pools page, click the name of a connection pool.

3.	Select the Monitoring tab.

4.	Click Pool Reset.