See if I can help with a brief picture here.

Imagine you are developing a web application using servlet API, in
the scenario that many of its services require access to certain
limited resource. In this case a database, for example. To access
this database, you need to provide connection objects. And for
better/faster response on user query, these connection objects should
be pre-created and pooled when the server first initialized. The
actual number of these pooled objects depends on what database you
are using. Microsoft Access, for instance, can provide up to 32
connections simultaneously (but note that it's redundant to do this
with Microsoft Access since it has its own internal connection pool).
As the web app running and multiple servlets dispatched, it is
possible that in the peak time the number of servlet instances --
that require access to the database -- is exceeding the number of
available connection objects. For this matter, you'll need to create
and deploy, say, a connection manager. Any servlet instance requiring
access to the database should go to the connection manager which in
turn checks any available connection object. If does available, it is
assigned to the servlet to work with. Otherwise, the sevlet(s) must
_wait_. When some other servlet is done working with a connection, it
should be returned to the conection manager which in turn _notify_
the waiting servlets that a connection is available (again). One of
these servlet instances will then -- in undetermined order -- be
picked to proceed with it.

Someone can create similar application with mere syncronized block,
of course. But there would be a great performance loss since, as I
can imagine, it may only utilize just one connection object  at a time.