Performance Tuning Guide > Tuning the Siebel Application Object Manager for Performance > Configuring Database Connection Pooling for AOMs >
Configuring Pooling for Default Database Connections
Default database connections can be used by most AOM operations.
Configuring Parameters for Pooling Default Connections
This section describes how to enable or disable pooling for default database connections using the parameters MaxSharedDbConns (DB Multiplex - Max Number of Shared DB Connections) and MinSharedDbConns (DB Multiplex - Min Number of Shared DB Connections).
- To enable connection pooling, set MaxSharedDbConns and MinSharedDbConns to positive integer values (at least 1) that are no higher than MaxTasks - 1. 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.
- To configure persistent and shared database connection pooling, set MaxSharedDbConns, using the appropriate ratio of MaxTasks/MaxSharedDbConns. Depending on the ratio, a greater or lesser degree of sharing will be in effect. Start with a 2:1 (or smaller) ratio for MaxTasks/MaxSharedDbConns. With this example ratio, two user tasks will share the same database connection.
- To configure persistent but nonshared database connection pooling, set MaxSharedDbConns = MaxTasks - 1.
- To disable connection pooling, set MaxSharedDbConns and MinSharedDbConns to -1 (this is the default value).
MaxSharedDbConns and MinSharedDbConns are defined per AOM component, on an enterprise basis (these parameters are included in named subsystems of type InfraDatasources). The database connections these parameters control are not shared across multithreaded processes. The actual maximum number of database connections for each multithreaded process is determined by the ratio MaxSharedDbConns/MaxMTServers.
NOTE: MaxSharedDbConns and MinSharedDbConns work differently than MinTrxDbConns, which specifies the number of shared specialized database connections available for each multithreaded process. For details, see Configuring Pooling for Specialized Database Connections.
Example Configuration for Pooling Default Connections
Assume, for example, the following parameter settings:
MaxTasks = 500
MaxMTServers = 5
MinMTServers = 5
MaxSharedDbConns = 250
MinSharedDbConns = 250
With these settings, the AOM component can support a maximum of 500 tasks (threads). Those 500 tasks would be spread over five multithreaded processes, each having 100 tasks. Each multithreaded process would have a maximum of 50 shared database connections, each of which would serve up to two tasks.
How Pooled Default 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:
- If a database connection is available in the pool that is not being used by another session managed by the same AOM multithreaded process, assign the connection to the new session. The connection is not removed from the pool.
- If the number of connections in the pool is less than MaxSharedDbConns, create a new connection, place it into the pool, and assign it to the new session.
- Select the current connection in the pool that is shared by the fewest sessions (has the lowest usage count), and assign it to the new session.
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 that were managed by this process are closed.
Scenario for Assigning Pooled Default Connections
Assuming, for example, the parameter settings described in Example Configuration for Pooling Default Connections, shared database connections will be handled as in the following scenario:
- If 10 users log in, in sequence, each user is assigned a new database connection on the same multithreaded process. (Each multithreaded process will have at most 10 shared database connections.)
- User 21-100, continuing to log in (in sequence), would reuse these connections.
- Users 51-100, logging in (in sequence again), would reuse Connections 1-50. (Each database connection will have at most a usage count of 10. Each multithreaded process would have at most a thread count of 100.)
- Once assigned a database connection, a user session is tied to that database connection for the duration of the session. This mapping is maintained until the user logs out or the session times out.
- So, assuming 100 users have logged in, in sequential order, then Connection 1 is then used by Users 1, 11, 21, 31, 41, 51, 61, 71, 81, and 91.
- When a user logs out or session timed out, the usage count for Connection 1 decrements by 1. (Connections with lower usage counts will be assigned to new user sessions, as needed.)
- Once the usage count for a database connection reaches 0, it is closed if the number of database connections is greater than MinSharedDbConns. If it is equal to or less than MinSharedDbConns, then it is not closed.
For details, see How Pooled Default Connections Are Assigned.