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