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.
Back to the Question
The MSDN article is saying that its specific object pool implementation will increase the size of the pool up to the specified maximum. When the maximum is reached, unlike the example above, instead of throwing an exception, it makes the client wait until an object is returned to the pool, and then gives the newly returned object to the waiting client.
The MSDN article says that its specific connection pool implementation does not have a maximum size parameter - it will keep creating new connections to meet demand (eventually it will hit some system limit and the request will fail in some way that isn't specified).