A connection pool is an object pool that contains connection objects.
"Object pooling lets you control the number of connections you use, as opposed to connection pooling, where you control the maximum number reached."
An object pool allows an application to limit the number of instances in use at any one time. If the application needs more instances than the limit, the object pool has to decide how to deal with that problem. There are a number of possible strategies:
- return null
- throw an exception
- block until an instance is available
- increase the size of the pool
A connection pool is an object pool, so it has exactly the same decision to make.
A specific implementation of an object pool (or connection pool) could use any one of these strategies, or several in combination.
In my opinion the statement as quoted is misleading unless it is talking about specific implementations.
A Simple Object Pool Example
A pool has some configuration parameters. A simple pool might have a minimum_size and a maximum_size. When the pool is first available for use it will contain minimum_size objects. As clients ask for these objects, the pool will contain fewer unallocated objects. This number can also increase when clients return objects to the pool.
At some point the pool might reach a state where it has no unallocated objects, but one or more clients requests an object. At this point, as long as the pool hasn't reached maximum_size, it can create some new objects and add them to the pool. It can now return objects to the clients.
If the pool has reached maximum_size, it cannot increase the size of the pool, so it has to deal with the clients in a different way - let's say that it throws an ObjectPoolExhausted exception.
A little while later, some clients return objects to the pool, and it can carry on as usual until it runs out of objects again.