When an adapter service is invoked, either directly or from a flow service, the Integration Server adapter run time provides a connection object to the adapter service implementation (the WmAdapterService.execute() method). This section describes how connections are retrieved and managed and how to dynamically control the type of connection used for each service invocation.

At run time, all connection activity for adapter services is performed inside a transaction context that holds references to connections used while the context is open. (This is true regardless of whether the referenced connections are transacted.) There is an implicit transaction context that begins at the invocation of a top-level flow service (such as an HTTP invocation of an Integration Server service) and continues until that top-level service exits. Additional contexts may be created using the pub.art.transaction:startTransaction and ended using pub.art.transaction:commitTransaction or pub.art.transaction:rollbackTransaction. For more information on using these services, see the webMethods Integration Server Built-In Services Reference for your release.

When the Integration Server adapter run time retrieves a connection from a connection pool for use by an adapter service, a reference to that connection is placed in the transaction context, and the connection is not returned to the pool until the transaction context is closed. If another adapter service call is made within the transaction context, Integration Server will first determine whether a connection from the required connection pool and partition is in the context; if so, Integration Server will use the connection from the transaction context to the adapter service instead of requesting another from the connection pool.

When a connection is requested from a particular connection pool, the request may identify a partition in the form of an adapter-generated ConnectionRequestInfo object. A connection pool partition is a logical division within a given connection pool where connection objects in different partitions are used at different times in an adapter-defined way. If no ConnectionRequestInfo object is provided in the request, then the default (or null) partition is used. If the pool has an available connection in the specified partition, it marks that connection as busy and returns the connection to the caller. If not, (and the pool is not full,) then the pool requests a new connection from the associated connection factory, including any provided ConnectionRequestInfo object.