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

About Database Connections for Siebel Application Object Manager

This topic is part of Configuring Database Connection Pooling for Siebel Application Object Managers. It provides an overview of database connections for Siebel Application Object Manager components, including nonpooled connections and pooled connections. Subsequent topics provide guidelines and instructions for configuring different types of database connection pooling.

About Nonpooled Database Connections

If you do not pool database connections, then the number of database connections corresponds to the number of Siebel Application Object Manager sessions; that is, database connections are not pooled. No special Siebel Application Object Manager configuration is required for using nonpooled database connections. When no pooling is configured, database connections are closed when the user session terminates.

• Nonpooled default database connections. With nonpooled database connections, during session login, a database connection is established, using the user's database credentials. (When an external authentication system is used, such as LDAP, the user's database credentials might not be the same as the user's Siebel credentials.)

  This database connection becomes bound to the session, and is the default database connection used for read, write, update, and delete operations.

  In this book, such connections are called default database connections. These connections can alternatively be pooled, as described later in this topic.

• Nonpooled specialized database connections. If, during a session, specialized functionality is invoked that uses the external transaction management capabilities of the Siebel Application Object Manager, then a second database connection is opened for this specialized use.

  This database connection is also bound to the session, and is used for all externally controlled transactions performed by the session. Siebel EAI components are an example of specialized code that does external transaction management.

  In this book, such connections are called specialized database connections. These connections can alternatively be pooled, as described later in this topic.

About Pooled Database Connections

Optionally, you can configure your Siebel Application Object Manager components to support pooling for the same two types of database connections described previously for nonpooled database connections:

• Pooled default database connections. These database connections can be pooled to support sharing (multiplexing), persistence, or both features.
  • Shared connections support multiple user sessions at the same time, by multiplexing (sharing) database operations for multiple SQL statements over the same database connection. Using shared connections can support more users with a given number of connections.
  • Persistent connections are pooled, but are not necessarily shared. Using persistent connections can enhance performance by avoiding the cost of creating database connections. All shared connections are also persistent connections.

    For details, see Database Connection Pooling Usage Guidelines and Configuring Pooling for Default Database Connections.

• Pooled specialized database connections. These database connections are dedicated to a single session at a time, and serve a specialized purpose. Pooling such connections provides persistence, but such connections are never shared. By persistently pooling these connections, you enhance performance by avoiding the cost of creating connections.

  NOTE:  If you configure pooling for default database connections, but not for specialized database connections, then each specialized database connection is closed when the transaction that required it completes.

  For details, see Database Connection Pooling Usage Guidelines and Configuring Pooling for Specialized Database Connections.