JDBC folks at Sun:

Has there been any consideration regarding unsynchronizing the methods:
DriverManager.getConnection(...

It is generally bad form to synchronize and then call code over which you
have no control, and no way of  customer  whether or not it will return.

We have seen many cases here at our company, where all of our server threads
are hung in DriverManger.getConnection due to the fact that one thread
entered the method obtained the lock and the call never returns,
consequently every other thread ends up blocking behind getConnection.  We
have to explain that this is a class shipped with the JDK.  We can offer
workarounds of Driver.connect() but it is much cleaner to use DriverManager.
(Review ID: 94018) 
======================================================================

We can offer
workarounds of Driver.connect() but it is much cleaner to use DriverManager.
======================================================================

Changing this may now be easier given that vector is a syncronised collection. Anticipating fix this in next JDBC release.

  xxxxx@xxxxx   1999-09-10

Introducing a change such as this risks breaking existing applications that have
come to expect this behaviour. This has been the consistent manner in which JDBC enabled applications have acquired connections to datasources for a series of
J2SE releases. At this time, there is no industry mandate or requirement as to weather this behaviour should be modified to a standard or not.

However there remains an alternate route to avoid this synchronized behaviour:

Using the DataSource interface which was introduced in the JDBC 2.0 Optional package. This is now available as part of the J2SE 1.4.0 FCS. A JDBC driver that
implements the DataSource interface returns connections that implement the
Connection interface in much the same as Connection objects are returned
by the DriverManager class. Using the DataSource interface also improves
application portability by allowing a logical name for a data source removing
the specific need to tie down information to a particular driver, but
additionally avoiding the syncrhonization currently present in the DriverManager
class.

  xxxxx@xxxxx   2002-02-13

Please fix this bug. I'm also having deadlock in shipped code because one of the JDBC
driver configured in my system blocks, keeping the monitor on the DriverManager
and preventing any use of JDBC in the whole system!
This reproduces in JDK 1.3.0_1

This report should not be flagged as RFE but rather BUG! Other "bugs" are closed as duplicate of this one!

Workaround: patch DriverManager yourself and append the patched version at the head of the boot path

One can very easily patch the synchronization of DriverManager by reducing synchronization from method 
scope to smaller synchronized block applying on the "drivers" static member field, and taking our the 
blocking calls such as di.driver.acceptsURL(url) and di.driver.connect(url, info) out of the 
synchronized iterating loops.
I have a patched version of DriverManager if this can help.

I often encounter this same problem whenever the network 
connection to a remote db is bad. does anybody know if this 
has been fixed in the later release of JDK? how can i get 
a "patched version of DriverManager"?

Why is this bug closed?  This is a serious problem that 
needs to be fixed.  Developers should not have to patch 
DriverManager for every JDK release.  

whats up? why is this still synchronized?

Sun's high handed approach to this serious problem is
unbelivable! First they refuse to acknowledge a bug ( it is
not per their own spec). Then they expects us to wait until
a 3rd party vendor implements a workaround for them.

When we use Datasource will it resolve this issue?

This appears to be fixed in JDK6.