PDContext application design considerations

This section explains some aspects of PDContext application design to consider.

For detailed information about PDContext pooling class, see the Javadoc HTML documentation. There are a few points to consider before we use the PDContext class to design applications, such as:

• How many applications use PDContext concurrently?
• How many users per application use PDContext?
• Will the application initiate administrative requests to the Policy Server? If yes, is it handled by a single user or many users?

The most important concept to remember when you design an application that uses the PDContext class is that PDContext objects must be reused whenever possible. Do not create a PDContext object for every operation. Doing so quickly exhaust the sessions available on the server.

For every PDContext object created by your application, a session is created and maintained on the Policy Server. The validity of the session is controlled by the ssl-v3-timeout parameter in the pd.conf file. The default value for ssl-v3-timeout in thepd.conf file is 7200 seconds (2 hours).

Each PDContext object can manage several connections. However, only one connection is active per context at a time. Other connections are queued up and blocked until the current connection is completed, allowing the next connection to complete. By default each PDContext object supports 10 connections. The connection support is advantageous in multithreaded applications which allow multiple threads to easily share a PDContext. This approach is best for application with few threads and only occasional requests to the policy server.

The number of PDContext objects created represents the number of concurrent requests that are handled by your application. For applications that require many threads and frequent requests to the policy server, the PDContext objects must be maintained in a pool where PDContext objects are checked out as needed and returned when the operation completes. Depending on the number of threads and the number PDContext objects in the pool, the approach yields good performance results. Application requirements vary considerably depending on the goal. As a result, we can provide only general guidelines on a PDContext Pool design. Basic requirements include:

• Maintain the pool as a private class variable.
• All methods that access the pool must be synchronized.
• Start with a pool size of 10 PDContext objects and adjust as needed to improve performance.

• Create PDContext objects can take a lot of time. Avoid the use of large pool sizes.

• To improve overall performance, do not create PDContext objects immediately. Initialize the pool when the application starts, instead.

Parent topic: Use the administration API