Category Archives: drcp
Oracle DRCP and OCI JDBC Driver
Database Resident Connection Pooling(DRCP), a new feature of Oracle Database 11g pools database server processes and sessions (the combination is known as a pooled server), which are shared across connections from multiple application processes from the same host or from different hosts. A Connection Broker process (a background process in oracle) manages the pooled servers in the database instance. Clients are persistently connected and authenticated to the Broker.
A good resource to understand DRCP can be found here .
Enabling and Configuring the pool:
Every database instance of 11g has a default pool. The pool needs to be started before the clients can request for connections. The command below brings up the Broker, which registers itself with the database listener. This command needs to be execute using the DBA account.
SQL> execute dbms_connection_pool.start_pool;
Here dbms_connection_pool is the package name and start_pool is a stored procedure. A similar procedure named “stop_pool” exists to stop the connection pool.
Routing client connections to DRCP:
Currently DRCP interface is available for OCI and OCCI clients using TCP/IP protocol and simple database authentication (userid/password based). The clients must specify the server type as POOLED via the connect string as shown below:
myhost.dom.com:1521/sales:POOLED
OR
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=myhost.dom.com) (PORT=1521))(CONNECT_DATA=(SERVICE_NAME=sales) (SERVER=POOLED)))
Using OCI JDBC Driver
Currently the OCI JDBC Driver (version 11.2.0.1.0) does not have the support to make appropriate calls to OCI for DRCP and the strange fact is that the driver does not throw any exceptions which states that this feature is not supported.
If your java application tries to connect to the oracle database server instance using the above connection string after starting the connection pool, the application would be able to create connections to the database but on the database server every connection request would create a new connection/process instead of reusing the pooled one. This can be verified by querying the system view named ‘V$CPOOL_STATS’