RFR 8060068 : Remove the static initializer block from DriverManager

[Mandy Chung]

Hi Bernd,

On 12/2/14 1:49 PM, Bernd Eckenfels wrote:
> Hello,
>
> just want to add two somewhat related observations:
>
> we have a virtual JDBC driver which maps back to an real driver (or to
> an Pool/Datasource which uses a real driver. This is to allow
> JDBC URLs to work in different environments with no config. (Thats is
> not the nices solution, but after we resolved the deadlocks it
> works stable with the legacy code we need to support).

Would you be able to try this patch and see if the deadlocks are 
reproducible?  Lance has been trying to get customers to verify this 
patch as this code has been deadlock-prone.  Your feedback would be very 
useful.
> This does have two consequences which are related to this patch:
>
> a) #getConnection() is used quite often, as it tunnels through to a
> high performing pool (already mentioned as a good reason for DCL).

Once the drivers are loaded and initialized (once), getConnection would
not need any locking (it just checks the volatile boolean field).

Do you see any potential performance issue with it?

>
> b) there have been some deadlock conditions in the past in this area. I
> can try to find the details later on, but it involved class
> loading/registration and the driver's synchronized.

This may be similar to the deadlock problem reported in this bug
during the class initialization of DriverManager class and the
driver classes (that also triggers DriverManager.<clinit>)

This patch changes the loading/registration of the drivers to be
lazy at the first time when getConnection, getDriver, getDrivers
is called.  No synchronized is done afterward.

I'm foreign to the JDBC spec and implementation and I may miss
some subtle issue here.

> So it is a bit risky (assuming we are not the only ones using the SPI
> in this creative way) to play with the locking.
>
> At the same time, it is also needed. Maybe the more finegrained lock
> and the lock-free happy path help with it. I wonder, is there a
> special procedure to warn in the release notes/compatibility guide
> other than having the patch listed in a changelog? In order to warn
> people switching to 9 (in 5 years or so :).

Yes the current way is to tag the JBS issue with "release-note=yes" and 
add the suggested release note in the bug.

On the other hand, if this fix is high risk, we should re-evaluate if 
this should be fixed differently.  This fix is not intended to cause any 
behavioral incompatibility.   Is that your concern with this patch?

Mandy