Connection pooling for web services

Each database that exposes web services has access to a pool of database connections. The pool is grouped by user name such
that all services defined under a given USER clause share the same connection pool group.

A service request executing a query for the first time must go through an optimization phase to establish an execution plan.
If the plan can be cached and reused, then the optimization phase can be skipped for subsequent executions. HTTP connection
pooling leverages the plan caching in database connections by reusing them whenever possible. Each service maintains its own
list of connections to optimize reuse. However, during peak loads, a service can steal least utilized connections from within
the same user group of connections.

Over time, a given connection may acquire cached plans that can optimize performance for the execution of a number of services.
For more information about cached plan settings, see max_plans_cached option.

In a connection pool, an HTTP request for a given service tries to acquire a database connection from a pool. Unlike HTTP
sessions, pooled connections are sanitized by resetting the connection scope environment, such as connection scope variables
and temporary tables.

Database connections that are pooled within the HTTP connection pool are not counted as connections in use for the purposes
of licensing. Connections are counted as licensed connections when they are acquired from the pool. A 503 Service Temporarily Unavailable status is returned when an HTTP request exceeds the licensing restrictions while acquiring a connection from the pool.