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 <[email protected]>: > 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
