RFR 8060068 : Remove the static initializer block from DriverManager

Bernd Eckenfels ecki at zusammenkunft.net
Tue Dec 2 23:33:43 UTC 2014


Hello Mandy and Lance,

(sorry, not a full quote for more focused answers, inline)

Am Tue, 02 Dec 2014 14:10:06 -0800
schrieb Mandy Chung <mandy.chung at oracle.com>:

> 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.

Hm, I might be able to test it with the unit tests (once I get the
binary to build). Currently I cant test the whole system with 8 or 9
(do you think porting it to 7 might be straight forward?). I think the
Unit tests have no reproducers for this issue, will check.

> > 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?

No, dont see a problem. I wanted to add another vote pro DCL.

> 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>)

Yes, all related.

> 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?

I will have to find the stack traces from well-back-than where we had
the deadlocks and compare it with the proposed patch. Up until now it
is just a mild suspect :)

Greetings
Bernd



More information about the core-libs-dev mailing list