Overview of Pooling

What Is Pooling?

Pooling is a feature of SAS clients that increases the efficiency of connections to SAS. Pooling is only available for SAS Workspace Servers.

How Pooling Works

When a SAS client application is configured to access a pooled workspace server, the client application maintains a collection of reusable workspace server processes called a pool. By reusing server processes, pooling avoids the processing that is associated with creating a new process for each connection. If your client application uses frequent, quick connections to SAS, pooling might greatly improve your server performance.

The server processes within a pool are divided into one or more puddles. A puddle is a group of server processes that are accessible to a specific user group and that connect to SAS by using a single set of credentials called the puddle login.

The metadata administrator might choose to create several puddles to control the data that users are authorized to access. Because the SAS server uses the puddle login both to connect to the metadata and to run the server process, this authorization (access control) can be applied in the metadata or on the physical data (using file system authorization).

For example, the metadata administrator might give one puddle read and write access to a table on an IOM server, while giving another puddle only read access.

Understanding the Connection Process

The following diagram shows a connection to a pooled workspace server:

The following process describes how a user retrieves and uses a pooled connection:

1. A user accesses a SAS client application, and the client requests a connection to SAS for the user.
   
   
2. The client application uses a special user called the pool administrator to connect to the SAS Metadata Server and read the pool metadata. The pool administrator must be able to view the metadata for all the logins (puddle logins) that are used to make connections for the pool. If you installed SAS by using the Configuration Wizard, the SAS Trusted User is the default pool administrator.

   Note: The pool administrator does not need to be able to view the login definition for the requesting user ID.

3. For each puddle, if the Minimum Number of Servers and Minimum Available Servers are not met, the client application uses the appropriate puddle login credentials to launch new server processes.
   
   
4. The pool determines which puddle the requesting user ID can access. The pool selects a puddle where one of the following is true:
   • The requesting user ID is a member of the group that is granted access to the puddle

   • The requesting user ID matches the puddle login's user ID, or is owned by the same user or group that owns the puddle login's user ID

   For example, in the preceding diagram UserB is a member of the Puddle2Access group. The Puddle2Access group has access to the Puddle2 puddle, so UserB will access Puddle2.

5. The pool returns a server connection from the selected puddle as follows:
   • If a server process is available, then the pool returns a connection to the requesting user.

   • If there are no available server processes, and the maximum number of server processes has not been met, the pool uses the puddle login to create a new server process and then returns a connection to the requesting user.

   • If there are no available server processes and the maximum number of server processes has been met, then the requesting user must wait for a server process to become available. When a process becomes available, the pool returns a connection to the requesting user.

   Note: For Java client applications, the pool balances the number of connections for each puddle among the server machines. For Windows client applications, all of the connections are assigned to the first server machine, until the maximum number of connections for that machine is met.

6. The user accesses resources and services on the SAS server. Authorization for content on the SAS server is performed using the puddle login.
   
   
7. When the user has finished using the server connection, the server process is returned to the pool, and it can be reused by other users.
   
   

Pooling with COM Connections

For COM connections, puddle logins are not used to launch SAS server processes. The credentials that the client application uses to launch the server processes are determined by your DCOM settings. It is generally not useful to create a pooled COM/DCOM configuration with multiple puddles.

The following process demonstrates how a user retrieves and uses a pooled COM connection:

1. A user accesses a SAS client application, and the client requests a connection to SAS for the user.
   
   
2. The client application uses the pool administrator's credentials to connect to the SAS Metadata Server and read the pool metadata.
   
   
3. For each puddle, if the Minimum Number of Servers and Minimum Available Servers are not met, the client application launches new server processes by using COM.
   
   
4. The pool determines which puddle the requesting user can access. The pool selects a puddle where the requesting user ID is a member of the group that is granted access to the puddle.

5. The pool returns a server connection from the selected puddle as follows:
   • If a server process is available, then the pool returns a connection to the requesting user.

   • If there are no available server processes and the maximum number of server processes has not been met, then the pool uses COM to create a new server process and then returns a connection to the requesting user.

   • If there are no available server processes and the maximum number of server processes has been met, then the requesting user waits for a server process to become available. When a process becomes available, the pool returns a connection to the requesting user.

   Note: All of the connections are assigned to the first server machine, until the maximum number of connections for that machine is met.

6. The user accesses resources and services on the SAS server. Authorization for content on the SAS server is performed using the user ID that created the server process.
   
   
7. When the user has finished using the server connection, the server process is returned to the pool, and it can be reused by other users.