Your "picture" is pretty much correct. I generally don't use the term "on client side" or "on server side", but more about "knowledge", ie, with a conventional connection pool, the client *knows* about the pool because it initiated it. The connections are still on the server not the client, but the client side has code that explicitly knows that its using a pool (OCISessionPoolCreate, OCISessionGet, OCISessionRelease, OCISessionPoolDestroy etc etc).

DRCP was invented because some application stacks don't have the concept of connection management really at all. They were designed in a day where every database interaction was:

a- establish a brand new connection
b- do some work
c- drop the connection

and (a) and (c) in oracle are expensive operations. So DRCP provides a "facade". The app *thinks* it is creating and destroying new connections, but we're "secretly" mapping that into standard connection pool management.

So if you code stack supports connection pooling (Java/JDBC, C#/Dot.net etc etc), then you'd typically manage it yourself. An exception sometimes to that rule is when the number of apps grow over time. You might start with 5 apps each and you're doing the right thing by keeping the connection pool size small for each with (say) a pool size of 10, totalling 50 connections. But in 5 years time, you've now got 200 apps...Now you have 2000 server connections. In that case, you might choose to change to DRCP to allow a pool that is shared across multiple apps to keep the connection count efficient.