1. Performance Tuning Guide
  2. Guidelines for Using Database Connection Pooling

Guidelines for Using Database Connection Pooling

If you decide to use database connection pooling, then observe the following guidelines:

  • Start with a low ratio of MaxTasks divided by MaxSharedDbConns, such as 2:1.

    Note: If you plan to use a ratio higher than 3:1, then it is recommended that you consult Oracle Advanced Customer Services. Contact your Oracle sales representative to request assistance from Oracle Advanced Customer Services.

  • If you have short (aggressive) average think times in your user scenarios, then use a smaller ratio of MaxTasks divided by MaxSharedDbConns. Longer think times can support larger ratios.

    For a 30-second think time, do not use a ratio higher than 10:1. For a 15-second think time, do not use a ratio higher than 5:1. Other factors discussed in this topic will also determine practical limits. For more information about think time, see Performance Factors for Siebel Application Object Manager Deployments.

  • Minimize long-running queries. Long-running queries can affect overall performance and must be minimized or avoided. If the current connection pool is blocked by a long-running query from one user session, then other user sessions will use a different pool. However, a long-running query can continue to run on the RDBMS even if the user who initiated it has stopped the browser.

    When you are using database connection pooling, it is critical to optimize database access in your environment. If long-running queries occur, then monitor the overall database response time. To achieve a satisfactory response time, use a small ratio of MaxTasks divided by MaxSharedDbConns.

    You can minimize or avoid long-running queries by providing the Cancel Query option for users, by adjusting indexes to include fields that can be sorted or queried by end users, by configuring the application user interface so that nonindexed fields are not exposed, and by training users to avoid operations that would perform long-running queries. For more information about how indexing can affect Siebel application performance, see Managing Database Indexes in Sorting and Searching. For more information about configuring the Cancel Query option, see Siebel Applications Administration Guide.

  • Consider the cost of creating database connections. This cost differs based on your authentication method.

    If your deployment uses database authentication, then a database connection is created for each login, for authentication purposes. Afterwards, this connection is released to the shared connection pool, if the total number of connections is less than the maximum. Or, if the pool is full, then 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.

    With external authentication, however, you can use persistent connection pooling to reduce the cost of creating database connections. With persistent connection pooling, database connections, once created, are persistent, though such connections might or might not be shared. For pooled default database connections where connections are persistent but not shared, set MaxSharedDbConns to equal MaxTasks minus 1. For more information about authentication options, see Siebel Security Guide.

  • In order to configure connection pooling for specialized database connections, you must also configure pooling for default database connections, as follows:

    • If you do not configure connection pooling for shared database connections (MaxSharedDbConns equals -1 or 0), then each specialized database connection, once created, is dedicated to the user session. The value of MinTrxDbConns is ignored.

    • If you configure connection pooling for shared database connections (MaxSharedDbConns has a value greater than 0, and less than MaxTasks), then specialized database connections are not dedicated to user sessions. Such connections are handled according to the setting of MinTrxDbConns:

      • If MinTrxDbConns equals -1 or 0, then, after the transaction that required it has ended, each specialized database connection is closed (deleted).

      • If MinTrxDbConns has a value greater than 0, then, after the transaction that required it has ended, each specialized database connection can return to the connection pool.

  • Siebel CRM does not support MTS or Oracle multiplexing features.