Chapter 4   Pooling Concepts


This chapter describes the concepts for setting up a pooling configuration node in the UIF repository.

The chapter contains the following sections:

• About Pooling

• Bind Durations

About Pooling

---

Pooling allows the ability to share scarce resources. In UIF, pools are used to share connections to a EIS from the iPlanet Application Server. UIF interacts with the enterprise connectors to allocate and reuse the pools to avoid unnecessary creation and destruction of connections to the EIS. Pools and their configuration information is defined in the repository for each datasource. In other words, each datasource defines its own connection pool which can be individually configured.

An object in a UIF pool represents a connection to an EIS. The maximum number of connections in the object pool may be specified in the repository. A pool typically contains the number of connections required for the application to maintain a steady state.

When an iPlanet Application Server application enables a service provider, the enterprise connector attempts to obtain a connection object from the pool. If the pools maximum size has been reached and no object is available after a specified waiting period, the request times out. The timeout period can also be configured in the repository.

If a pool object remains unused for a period of time, the object is destroyed. You can specify how long to wait before unused objects are destroyed.

The use and longevity of pool objects are monitored by UIF periodically. You can specify the interval in which the monitoring occurs. Typically, the monitoring thread executes more frequently than the waiting period before an object is destroyed. However, setting the monitor interval too small can degrade performance.

Pooling Configuration

The pooling configuration for a service provider is specified with the following characteristics in the repository:

Parameter	Description
SteadyPoolSize	The number of unused objects that are kept in the pool until they time out. (See UnusedMaxLife.) For example, if the pooled objects are host connections, set SteadyPoolSize to the steady state number of connections available from the host server.
MaxPoolSize	The maximum number of objects allowed in the pool. For example, if the pooled objects are host connections, set this number to the peak number of connections available to the server. If the number of objects exceeds SteadyPoolSize, objects are destroyed after they are returned to the pool.
MaxWait	The maximum time, in seconds, a request for a pooled object is held in the queue before the request times out and is destroyed.
UnusedMaxLife	The maximum time, in seconds, that a pooled object remains unused in the pool. After this time, the physical object is destroyed.
MonitorInterval	(Optional) The time, in seconds, that a thread is executed to monitor the current status of the pool. Default is 30 seconds. Typically, setting this number too low degrades performance, but it should be set to a number less than UnusedMaxLife.
DebugLevel	(Optional) Determines type of message logging, as described by the following choices: 0: Logging turned off. 1: Logs only callback messages. 2: Logs all messages.

Bind Durations

---

A pooled connection is bound to a J2EE component for a specified period of time, called the bind duration, which is specified in a service provider type. Typically, the bind duration is only for the length of time it takes to execute a single method requiring the connection. Some operations, such as beginning a transaction, may require a longer bind duration.

Bind durations are specified in the repository. UIF supports three bind durations, as follows:

Bind Duration	Description
method-bound-poolable	The pooled connection is bound for the duration of the method call.
sp-bound-poolable	The pooled connection is bound for the life of the service provider; then the connection is returned to the pool.
not-poolable	The connection is not poolable. The connection is bound for the life of the service provider and is destroyed when the service provider is destroyed.

Bind Duration Escalation

The bind duration may be changed dynamically by the enterprise connector. For example, at the beginning of a transaction, an enterprise connector may escalate the bind duration from method-bound to sp-bound, and reset the bind duration to method-bound when the transaction completes.

Bind Duration Timeouts

An sp-bound connection cannot be used by another service provider until the connection has been released by the first service provider. If the first service provider does not release the connection in a timely manner, a timeout occurs and the connection is forcibly released and returned to the pool. The timeout prevents a run away service provider that failed to call disable() from keeping the connection indefinitely.