Programming Guides › Connector Programming Guide › Implementing Connectors › Style Processors › Connection Pooling Considerations

Connection Pooling Considerations

Wherever possible, write ConnectionManager implementations as pools to provide scalability benefits. The utility class com.ca.jcs.cfg.GenericObjectPoolConnectionManager* is useful in case the endpoint system does not have connection pooling built-in. If this approach is used, the class derived from org.apache.commons.pool.PoolableObjectFactory (from the Jakarta Commons Pool open source library), which opens and closes connections accessed using the pool, does most of the work.

In most cases, it can be necessary to:

• Write a small class which extends BasePoolableObjectFactory and gets and releases connections in its makeObject() and destroyObject() methods. The pool uses this method to manage the raw connections it contains.
• Write another small stub class extending GenericObjectPoolConnectionManager which contains any additional custom logic you require.

  Note: For an example of how you to code such a manager and factory, see sdk.com.ca.jcs.jndi.JNDIConnectionFactor, com.ca.jcs.jndi.JNDIConnectionPool in the CA IAM CS Javadoc, in the CA IdentityMinder bookshelf, and the source files included with the SDK, which are bundled with the SDK.

Note: The com.ca.jcs.cfg.GenericObjectPoolConfigBeanWrapper class provides a mechanism for you to configure common properties on your pool using your connector's conf/connector.xml file.

You can specify a custom connection/pooling management class through the connectionManagerClass property in connector.xml which names such class. The CA IAM CS framework loads this class and creates an instance of the class provided a constructor with the signature Attributes, GenericObjectPool.Config, and Logger exists. The custom connection manager constructor is given all the connection-related attributes and is responsible for initializing itself into a state where it can then create connections using those attributes.

The activate() method is invoked when your connector's LDAP interface receives its first LDAP request after CA IAM CS is started. The method is also invoked when the client modifies any attribute you have flagged with the isConnection metadata. When the method is invoked, it does the following:

• Looks up the attribute values using the getAttributes() method
• Establishes a connection to the endpoint system (or preferably a connection pool).

  If the endpoint system cannot be contacted or the supplied credentials are invalid, the method throws appropriate LDAP exceptions.

When the connector receives a message from CA IAM CS that it is about to shut down, override the deactivate() method of your connector to perform any cleanup routines that you want to perform inside your connector. For example:

• Closing session pools
• Deleting temporary files
• Closing open references to files