Chapter 3   Pooling Concepts


This chapter describes pooling concepts when you set up a pooling configuration node in the UIF repository.

The chapter contains the following sections:

• About Pooling

• Bind Durations

• Pooling Configuration

About Pooling

---

Pooling allows you to share scarce resources. In UIF, pools are used to share connections to a backend system from iAS. Service providers allocate and reuse connections from pools to avoid unneccessary creation and tear down of connections to the backend. Pools are defined in the Repository on a per-datasource basis. 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 a backend system. Each pool contains a specified maximum number of objects to constrain the maximum number of simultaneous connections. A pool typically holds a number of objects that represent the number of connections in a steady state.

When a iAS application enables a service provider the connector attempts to obtain a connection object from the pool. If the maximum number has been reached and no object is available after a specified waiting period, the request times out. The timeout period can be configured.

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

The use and longevity of pool objects are monitored by a thread that executes periodically. You can specify the interval in which the monitor thread executes. Typically, the thread executes more frequently than the waiting period before an object is destroyed. However, setting the monitor interval too small can degrade performance. You specify the frequency in the MonitorInterval node of the pooling connection; for more information see Pooling Configuration.

Bind Durations

---

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

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 durations are specified in the repository. The following example shows that the <adaptor>Conn service provider type's bind duration is method-bound-poolable:

serviceProviderTypes
    <adaptor>Conn
       bindDuration string method-bound-poolable

Bind Duration Escalation

The bind duration may be changed dynamically by the connector. For example, at the beginning of a transaction, an 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.

Pooling Configuration

---

You specify the pooling configuration for a service provider by specifying the following characteristics in the repository:

Parameter	Description
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 is less than MaxPoolSize but exceeds SteadyPoolSize, objects are destroyed 3 seconds after they are returned to the pool.
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 (RMS) number of connections available from the host server.
MaxWait	The maximum time, in seconds, a request for a physical object is held in the queue before the request times out and is destroyed.
UnusedMaxLife	The maximum time, in seconds, that a physical 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.

The example below is used to show a "generic" pool, for specific information about your connector, see your connector documentation. The following entries define the pool configuration for the <adaptor>Conn service provider:

pools
    <adaptor>Pool
       sptype reference
       bsp.adapterTypes.<adaptor>.serviceProviderTypes.cicsConn
       config:do
          DebugLevel integer 1
          MaxPoolSize integer 20
          MaxWait integer 3
          MonitorInterval integer 10
          SteadyPoolSize integer 10
          UnusedMaxLife integer 300