Understanding the Client-side Pooling Connection Process

Consider an example of a client-side pool configuration that consists of:
  • two puddles: Puddle1 and Puddle2
  • two groups: Puddle1Access and Puddle2Access
  • two SAS server machines with an object spawner on each
The following figure shows a connection to a pooled workspace server:
The Connection Process for a Client-side Pooled Server
The Connection Process for a Client-side Pooled Server
The following process describes how a user retrieves and uses a client-side pooled connection:
Note: The pool administrator does not need to be able to view the login definition for the requesting user ID.
1 A user, User B, accesses a SAS client application, and the client requests a connection to SAS for the user.
2 The client application uses a special account called the pool administrator to connect to the SAS Metadata Server and to 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. The pool administrator also needs to be able to view the membership of the puddle access groups. 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.
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. (An example for this usage is rare: a single-user application wants to set up a personal connection pool for benefits such as reconnecting after an abnormal disconnect.)
In this example, User B is a member of the Puddle2Access group. The Puddle2Access group has access to the Puddle2 puddle. Therefore, User B will access Puddle2.
4 The pool manager 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 the puddle login to create a new server process and 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.
The user accesses resources and services on the SAS server. Authorization for content on the SAS server is performed by using the puddle login.
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.