-1

I am running apps in kubernetes, which for even one app, it may have multiple containers; thus, the jdbc pool won't work. Is there a layer similar to PgPool-II for oracle database?

Thanks in advance

  • Are you interested in just the "Connection Pooling" feature or do you want a comparison to all features? – Michael Kutz Jun 20 at 20:26
  • Mostly for the connection pooling feature, and it will be great if the apps can still use jdbc protocol – Accelerator Jun 21 at 14:34
1

From https://www.pgpool.net/mediawiki/index.php/Main_Page

Connection Pooling - feature of the database, Database Resident Connection Pooling

Limiting Exceeding Connections - limiting connections, feature of the database, PROFILE. Connection queuing, no such thing.

The above 2 are typically handled at application server layer.

Replication - disk mirroring can happen independently of the database, or using Automatic Storage Management, feature of the clusterware layer. For physical/logical replication, feature of the database: Introduction to Oracle Data Guard. For logical replication, feature of the database: Introduction to Oracle Streams, or other products such as Oracle Goldengate.

Load Balancing - feature of the clusterware layer, Load Balancing of Connections to Oracle RAC Databases

Watchdog - feature of the clusterware layer and the database, Introduction to Oracle RAC, Introduction to Oracle Data Guard, Application Continuity

In Memory Query Cache - feature of the database: Result Cache

0

Database Resident Connection Pooling sounds like the feature you seek.

When To Use Database Resident Connection Pooling

  • Database resident connection pooling is useful when multiple clients access the database and when any of the following apply:
  • A large number of client connections need to be supported with minimum memory usage.
  • The client applications are similar and can share or reuse sessions.
  • Applications are similar if they connect with the same database credentials and use the same schema.
  • The client applications acquire a database connection, work on it for a relatively short duration, and then release it.
  • Session affinity is not required across client requests.
  • There are multiple processes and multiple hosts on the client side.

Some of the other features of PGPool-II would require "special configuration" or are "not applicable" due Oracle's architecture.

Eg

  • Client Side caching requires the /*+ cache */ hint and the right driver. (OCI version, I believe)
  • Instead of the "share nothing" architecture that PGPool-II uses, you would use Real Application Cluster (RAC) and Standby Databases
    • The Listener can do round-robin Load Balancing across nodes
    • Standby Databases can be made Read Only (with Advance Data Guard license)
    • Transparent Application Failover (TAF) automatically moves connections from failed node to another node

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.