Siebel Performance Tuning Guide > Tuning Siebel Application Object Manager > Configuring Database Connection Pooling for Siebel Application Object Managers >

Database Connection Pooling Usage Guidelines

This topic is part of Configuring Database Connection Pooling for Siebel Application Object Managers.

Observe the following guidelines to help you determine if you must use database connection pooling, or to guide your deployment of connection pooling.

For more information about configuring the Siebel Application Object Manager parameters for database connection pooling mentioned below, see Configuring Pooling for Default Database Connections and Configuring Pooling for Specialized Database Connections.

When to Consider Using Database Connection Pooling

Consider implementing database connection pooling if, and only if, one or more of the following is true for your deployment:

• The RDBMS cannot support the number of dedicated user connections you would require if using nonpooled database connections. Pooling default database connections for shared use can reduce the number of connections you require.
• Memory resources are scarce on the Siebel Server computer on which the Siebel Application Object Manager is running. Pooling default database connections for shared use can reduce Siebel Application Object Manager memory requirements per concurrent user.
• Your deployment uses external authentication such as LDAP (that is, authentication other than database authentication), and creating new connections is slow on the database server. Pooling database connections can speed up login or other operations by providing persistent pooling, whether or not connections are also shared.
• You use a Siebel Server component that requires frequent logins for special-purpose processing. Pooling database connections to provide persistent connection pooling (not sharing) can provide a significant benefit for such components.
  • For Siebel Configurator, if you are using the component Siebel Product Configuration Object Manager (alias eProdCfgObjMgr_jpn in a Japanese locale), then it is highly recommended to configure persistent connection pooling. For more information about Siebel Configurator, see Tuning Siebel Configurator.

    NOTE:  Separate Siebel Application Object Manager components are provided for each installed and deployed language in which you can run your Siebel applications. For example, Call Center Object Manager for French is SCCObjMgr_fra.

  • For some other components, such as EAI Object Manager (when run in sessionless mode), it might also be helpful to configure persistent connection pooling.

    NOTE:  If session caching is configured for a component (by setting the parameter ModelCacheMax), then persistent connection pooling might provide little benefit. For example, session caching is typically configured for Workflow Process Manager. For more information about session caching for Siebel Workflow, see Caching Sessions.

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's Application Expert Services. Contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle's Application Expert 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. A database connection can process only one database operation at any particular moment. Therefore, if user sessions use all available connections in the database connection pool to execute long-running queries, then a new user session that requests a database connection is blocked until a database connection becomes available.

  For example, if a long-running query is run which takes, for example, three seconds, then, for this duration, database requests from another user who requires the same database connection are queued (blocked) until the query operation completes.

  A long-running query can continue to run on the RDBMS even if the user who initiated it has stopped the browser.

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

  Alternatively, long-running queries can be minimized or avoided by adjusting indexes to include fields that can be sorted or queried by end users, by configuring the application user interface so nonindexed fields are not exposed, or 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.

• 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, 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 = 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 = -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 = -1 or 0, then, after the transaction that required it has ended, then 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 database connection pooling cannot be used simultaneously with MTS or the Multiplexing features of Oracle Database.