SAS Integration Technologies pooling uses the SAS Object Manager's implementation as a COM singleton object so that only a single instance of the ObjectFactory component is created in any given process. This mechanism makes the same pools available to all callers in the same process.

Note: You define a pool by a logical name. When using ObjectPools.CreatePoolByLogicalName, a single pool can contain connections from multiple servers and multiple logins. When using ObjectPools.CreatePoolByServer, a pool consists of objects from a single server and a single login.

To implement pooling in your application:

Create the pool (use CreatePoolByServer or CreatePoolByLogicalName). You only need to create the pool one time, usually when the application is started. If you try to create a pool using a logical name that has already been used in a pool, you will receive an error.
Use GetPooledObject to get a PooledObject object from the pool. The PooledObject is a wrapper around the SASObject that is being pooled. This PooledObject wrapper is necessary to notify the pooling code when you are finished using the pooled workspace. When you use pooling, keep a reference to the PooledObject for as long as you keep a reference to the object.
Use the object for processing such as running a stored process and receiving output from SAS.
Use ReturnToPool to return the PooledObject object to the pool so it can be used again.
Release the object. In VB, you can release these objects by either letting them go out of scope or by calling
set obPooledObject = Nothing
The pool continues to run until either your process exits or you call Shutdown() on each pool. Releasing your reference to ObjectManager does not release the pool.

For example code, see SAS Object Manager pooling example.

In an ASP application, you can create a pool in one of two ways:

in the Application_OnStart callback in the global.asa
in the code that calls to get the PooledObject

When a pool is running, methods and properties are available on the SASObjectManager.ObjectPool object to look at statistics—how many total connections are in the pool, and how many are in use—about the pool, and shut down the pool.

Supplying Pooling Parameters Directly in the Source Code

To supply pooling parameters in the source code:

Create both a Server object and a Login object.
Fill out the relevant properties.
Pass the objects to ObjectManager.ObjectPools.CreatePoolByServer.

The following properties are used to configure SAS Integration Technologies pooling. You specify some of the properties on the LoginDef object and some of the properties on the ServerDef object.

ServerDef.MaxPerObjectPool: Specifies the maximum number of servers that should be created from the provided ServerDef object. A good starting place for this number is the number of CPUs that are available on the machine that is running SAS.
ServerDef.RecycleActivationLimit: Specifies the number of times that a workspace is used before the process it is running in is replaced. This is useful for capping any memory leaks or non-scalable resource usage. A value of 0 means to never recycle the processes.
ServerDef.RunForever: The value for this property must be either TRUE or FALSE. If the value is FALSE, then unallocated live connections will be disconnected after a period of time (specified by the value of ServerDef.ShutdownAfter). If the value is TRUE (the default value), unallocated live connections will remain alive indefinitely.
ServerDef.ShutdownAfter: Specifies the number of minutes that an unallocated live connection will wait to be allocated to a user before shutting down. This property is optional and it is ignored if the value of ServerDef.ServerRunForever is TRUE. The value must not be less than 0, and it must not be greater than 1440 (the number of minutes in a day). The default value is 3. If the value is 0, then a connection returned to a pool by a user will be disconnected immediately unless another user is waiting for a connection from the pool.
LoginDef.MinSize: Specifies the minimum number of workspaces using this LoginDef that are created when the pool is created.
LoginDef.MinAvail: Specifies the minimum number of workspaces using this LoginDef that need to be available. Note that MaxPerObjectPool will never be exceeded.
LoginDef.LogicalName: This is only used when a pool is created using CreatePoolByLogicalName. It is used to determine which set of LoginDefs in LDAP to use in the pool.

For more information about the client-side coding for pooling, see the online Help shipped with the Object Manager.

Administering Pooling Using a SAS Metadata Server

When using a SAS Metadata Server with the SAS Object Manager, you create a pool by specifying a logical name that matches a logical server name on the SAS Metadata Server.

The administrator can associate puddles with the pooled logical server name and administer pooling and puddle parameters using SAS Management Console. For more information, see Planning and Configuring Pooling in the SAS Integration Technologies: Server Administrator's Guide.

Authentication and Authorization Checking

The authentication and authorization checking in SAS Integration Technologies pooling allows you to create a pool that contains connections that have been authenticated using different user IDs. This is useful for allowing the access to sensitive data to be controlled on the server machine instead of the middle tier.

Checking is only performed in pools that were created with CreatePoolByLogicalName where the checkCredentialsOnEachGet parameter is set to TRUE.

Authentication is performed by using the user ID and password to authenticate a new connection to a SAS Metadata Server. The pool is searched for a puddle whose access group has the authenticated user as a member.

Authentication is performed using the following steps:

Binding to the SAS Metadata Server using the credentials provided to GetPooledObject.
If that bind fails, then GetPooledObject will return an error.
If that bind is successful, then it is released and not used; it is only connected to authenticate the credentials. Authorization is then performed against the set of identities in the puddle:
- If a match is not found, then ERROR_ACCESS_DENIED is returned (0x80004005).
- Otherwise, a pooled object is returned when one becomes available.

Administering Pooling Using an LDAP Server

For LDAP, you can specify pool parameters using the IT Administrator. For more information, see Setting up Workspace Pooling in the SAS Integration Technologies: Administrator's Guide (LDAP Version).

Authentication and Authorization Checking

Checking is only performed in pools that were created with CreatePoolByLogicalName where the checkCredentialsOnEachGet parameter is set to TRUE.

Authentication is performed using the following steps:

Binding to the LDAP server using the referenceDN and referenceDNPassword provided to GetPooledObject.
If that bind fails, then GetPooledObject will return an error.
If the bind is successful, that connection will be released, and the main LDAP connection will then be used to look up the allowedClientDN attribute on logins that are appropriate for the requested pool.
- If a match is not found, then ERROR_ACCESS_DENIED is returned (0x80004005).
- Otherwise, a pooled object is returned when one becomes available.

Use of this feature allows user IDs and passwords to be used by people who are not allowed to know what those user IDs and passwords are (assuming the security settings are specified properly on the LDAP server). Only the userDN specified in SASObjectManager.SetLDAPUser needs to have access to the login information.