This part of the documentation is designed to answer the following questions:

The MTS provides a standard model for administering resource pools. Communication between MTS components (MTS business objects) and the R/3 system happens via RFC connections.
Each RFC connection is associated in the R/3 system with a user context that is kept in a "roll area" of the application server. The R/3 user context contains the authorizations of the calling R/3 user as well as any temporary results of the current call.

These RFC connections are the expensive resources whose use by business objects is optimized via the pooling mechanism of the DCOM Connector. RFC connections no longer needed by an object are not released but kept in a resource pool and can be reused by the same or any other object.
Thus resources can have different states:

• As free resources, they are stored in a pool.
• As resources associated with an object, they are activated by the object that uses them for RFC accesses.

Especially in scenarios where several users share an R/3 user (WEB scenario), high performance of the R/3 accesses is important to keep response times short. The pooling mechanism allows faster access to a required RFC connection and faster association of it with an object. Performance is lower if for each access the connection has to be established first.

In addition, a minimized number of user contexts reduces the storage space required on the application server of the R/3 system.

The figure below shows the relations between the components that participate in resource pooling.

A resource is identified by the following basic data:

• Destination
• Client
• User
• Password
• Language

If a suitable free resource exists in the pool, the Dispenser Manager is asked to make it available. The Dispenser Manager is responsible for resource pool administration and for eventually passing the resource to the Dispenser.

If the pool does not contain a suitable resource, the Resource Dispenser establishes a new RFC connection using the transferred basic data. An RFC connection is associated to the respective MTS business object until one of the following methods is called:

• CommitWork( )
• SetComplete( ) or SetAbort( )

After one of these methods was called, the system dissociates the RFC connection from the current object. The resource, which is now free, is passed to the pool in a separate thread. Returning the resource to the pool dissociates the R/3 user context from the current object. Any subsequent method call of the same or any other object will use a new R/3 user context. The thread that returns the resource to the pool then starts to delete the R/3 user context on the application server.

In Release 3.XX the user context was deleted using the function RfcClose( ) and RfcOpen( ). In the new R/3 Releases 4.XX, you can achieve this also using OK code "/n".

Objects that exclusively call stateless BAPIs or remote function modules can, in addition, use the option Pooling of R/3 Context to improve performance. If this option is set, the system suppresses the deletion of the user context in the R/3 work process. Only the resource is returned to the pool. In this case, the time required for a round trip to delete the context in the R/3 work process and the time for initializing a new context can be saved.

The life of a resource is determined by two parameters:

By default, the parameter MaxTimeToKeepAlive is preset to a value of 300 seconds and MaxTimeToKeepInPool is preset to 200 seconds. The maximum life span of a resource with this specification can be 300 seconds plus the time additionally needed to process the current call.

The figure below demonstrates the use of resources by MTS business objects under consideration of the respective life spans.

The figure presumes the following simplifications:

• In a transaction exactly one BAPI call is executed. Usually, several BAPIs can be included into one transaction.
• The option Pooling of R/3 Context is not set.