Previous Contents Index DocHome Next |
iPlanet Unified Integration Framework Developer's Guide |
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
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 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:
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.
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.
The maximum time, in seconds, a request for a physical object is held in the queue before the request times out and is destroyed.
The maximum time, in seconds, that a physical object remains unused in the pool. After this time, the physical object is destroyed.
(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.
(Optional) Determines type of message logging, as described by the following choices:
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
Previous Contents Index DocHome Next
Copyright © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.
Last Updated June 08, 2000