Performance Tuning Guide > Tuning the Siebel Application Object Manager for Performance > Best Practices for AOM Tuning >

Configuring Shared Database Connection Pooling

Shared database connections are used by most AOM operations. A connection will be shared by more than one user session once the number of sessions within the multithreaded process exceeds the maximum number of shared connections allowed per process, as explained below.

Configuring Parameters for Shared Connection Pooling

This section describes how to enable or disable connection pooling and multiplexing using the parameters MaxSharedDbConns and MinSharedDbConns. These parameters are included in named subsystems of type InfraDatasources.

To configure parameters for shared database connections

  1. Determine the appropriate number of user tasks that should share a database connection.
  2. Start with a 10:1 ratio for MaxTasks/MaxSharedDbConns: in other words, 10 user tasks will share the same database connection.
  3. Adjust the ratio based on think time. The 10:1 ratio assumes a 30-second think time. For a 15-second think time, reduce the ratio proportionally, to 10/(30/15) = 5:1.
  4. Adjust the ratio lower if there are known long-running queries in your deployment.

NOTE:  A long-running query on a shared database connection may block other users sharing that database connection. Therefore, it is critical to optimize database access in your environment when using database connection pooling. If long-running queries cannot be avoided, monitor the overall database response time and reduce the ratio MaxTasks/MaxSharedDbConns accordingly, until a satisfactory response time is achieved.

Example Configuration for Shared Connection Pooling

Assume, for example, the following parameter settings:

MaxTasks = 500

MaxMTServers = 5

MinMTServers = 5

MaxSharedDbConns = 50

MinSharedDbConns = 50

With these settings, the AOM component can support a maximum of 500 threads. Those 500 threads would be spread over five multithreaded processes, each having 100 threads. Each multithreaded process would have a maximum of 10 shared database connections, each of which would serve up to 10 threads.

NOTE:  Adjust the ratio based on think time. For example, if think time is 15 seconds, then the ratio would be 10/(30/15)=5:1, and MaxSharedDbConns = 500/5=100.

How Shared Connections Are Assigned

When the AOM starts up, the shared connection pool is empty. When a user logs into the AOM, the shared connection pool is checked to see if a connection is available.

Shared database connections may be assigned to a new user session in any of the following ways:

Once a shared connection is assigned to the new session, all database operations (read, write, update, and delete) for the session go through the connection.

When the session terminates, the usage count for the database connection is decremented. If the usage count has reached 0 (no sessions use this connection) and there are at least MinSharedDbConns connections already in the pool, the connection is removed from the pool and closed. Otherwise, it is left in the pool so the minimum number of shared connections is maintained.

When an AOM multithreaded process shuts down, any remaining connections in the pool are closed.

Database Connections and Database Authentication

When your deployment uses database authentication, a database connection is created for each login, for authentication purposes. Afterwards, this connection is released to the shared connection pool, if it has less than MaxSharedDbConns. Otherwise, if the pool is full, the connection is closed (terminated).

Therefore, even when the pool is full and connections are available, new connections are still created temporarily for each new session login. These connections must be accounted for in determining the allocation of database connections.

Database Connections and Long-Running Queries

When multiple user sessions are assigned to a shared database connection, all database operations from these users go through this shared connection. A database connection can process only one database operation at any particular moment.

If a long-running query is run which takes, for example, three seconds, then, for this duration, database requests from other users sharing the same database connection would be queued until the query operation completes.

For this reason, when you use database connection pooling, it is critical to minimize the number of long-running queries.

Scenario for Assigning Shared Connections

Assuming, for example, the parameter settings described in Example Configuration for Shared Connection Pooling, shared database connections will be handled as in the following scenario:

For details, see How Shared Connections Are Assigned.

 Performance Tuning Guide 
 Published: 24 October 2003