Oracle client interface (OCI) pooling for PowerBuilder applications is created when you connect to an Oracle server for the first time. The pooling is identified by the server name and character set which are passed in the DBParm parameters SQLCA.ServerName and NLS_Charset, respectively. If two Oracle connections are connected to the same Oracle server but use different character sets, the connections must reside in different connection or session pools. All pooling-related DBParm parameters must be set before the initial database connection.
Session pooling means that the application creates and maintains a group of stateless sessions to the database. These sessions are passed to clients as requested. If no session is available, a new one is created. When the client is done with the session, the client releases it to the pool. With session pooling, the number of sessions in the pool can increase dynamically.
Session pooling does not support external authentication using an OS account. If a Login ID is not specified in a database connection using an existing session pool, the Login ID of the session pooling creator is used for the connection.
The O90 and O10 database drivers that you can use in PowerBuilder to connect to the 9.x and 10.x versions of the Oracle DBMS support connection pooling with the DBParm parameter CNNPool. For backward compatibility purposes, this parameter is also supported by the ORA driver that you use with Oracle 11g. However, if the Pooling parameter is used with this driver, the CNNPool parameter is ignored.
The following table describes the circumstances under which you should make your pooling selection:
Choose |
When database sessions are |
|---|---|
Session pooling |
Stateless (reusable by middle tier threads) and the number of back-end server processes can cause database scaling problems. |
Connection pooling |
Stateful (not reusable by middle tier threads) and the number of back-end server processes can cause database scaling problems. The number of physical connections and back-end server processes is reduced by using connection pooling. Therefore many more database sessions can be utilized for the same back-end server configuration. |
No pooling |
Stateful (not reusable by middle tier threads) and the number of back-end server processes will never be large enough to cause scaling issues for the database. EAServer components and MTS components do not support either type of pooling for Oracle databases. |
The Oracle Real Application Clusters (RAC) database option allows a single database to be hosted in multiple instances on multiple nodes of the database server. This adds high availability and failover capacity to the database.
Connect time load balancing Balancing of work requests occur at two different times: connect time and runtime. Connect time load balancing occurs when a session is first created by the application. This ensures that sessions that are part of the pool are well distributed across RAC instances, and that sessions on each of the instances have a chance to execute work.
For session pools that support services at one instance only, the first available session in the pool is adequate. When the pool supports services that span multiple instances, work requests need to be distributed across instances so that more requests go to the instances with greater capacity or that provide better service.
Runtime connection load balancing You can also use runtime connection load balancing to direct work requests to the sessions in a session pool that best serve the work. Runtime connection load balancing is enabled by default when an Oracle 11.1 or higher client is connected to a release 10.2 or higher Oracle server using OCI session pooling.
The DBParm parameter, RTConnBalancing, supports the runtime connection load balancing feature. It is available only when the Pooling parameter is set to Session Pooling, and it can be set before connection only. By default, when you select Session Pooling for the pooling type, the RTConnBalancing value is true.
