Pragmatically speaking, the best way to limit the number of connections, without breaking applications in the process, is to use a transaction-processing subsystem to coordinate and balance the workload in the system as a whole.
The idea is, not only do you limit the number of connects that are attempted, but you also regulate the workload so that the system never attempts to exceed that limit.
When computers are flooded with requests, and there is no request-throttling subsystem, they blindly attempt to serve all those requests and begin to "thrash." When this happens, performance declines precipitously and suddenly: the so-called "elbow" in the performance curve, or more simply, "hitting the wall," "crash and burn." Yet if the requests are throttled even only slightly, all of the requests will be processed in a timely and predictable manner. If you know that you'll be sending 200 simultaneous requests against any database server, you can also be sure that load-controls of other types will be needed elsewhere.