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
