db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1459) Early load of Derby driver with JDBC 4.0 autoloading can lead to derby properties not being processed or derby boot time actions consuming resources when a connection is made with another driver
Date Wed, 28 Jun 2006 19:39:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1459?page=comments#action_12418299 ] 

Daniel John Debrunner commented on DERBY-1459:
----------------------------------------------

The functional behaviour of EmbeddedDriver changes with this patch.

Previously calls to the java.sql.Driver methods of EmbeddedDriver defered to the currently
registered driver in DriverManager. Now they defer to a specific instance of the AutoloadedDriver
which may not be registered with the DriverManager. Through the logic I think this means that
the calls can throw an exception when they would previously succeed. This would be in the
case the Derby driver had been loaded, unloaded and then loaded again. Seems to me that EmbeddedDriver
should not change with this patch.
Even without an unload there is a chance (due to concurrent booting) the AutoloadedDriver
stored in EmbeddedDriver is not the currently active one (ie. one registered with the DriverManager).

Second issue that calling one of the methods of java.sql.Driver methods on EmbeddedDriver
will now automatically load the Derby driver, whereas currently an exception will be thrown,
driver not registered. Maybe this is intentional, it would be good to call this out. I'm not
sure it is a good idea, adds a new non-standard mechanism for autoloading, and we've seen
what  issues the standard autoloading has!


> Early load of Derby driver with JDBC 4.0 autoloading can lead to derby properties not
being processed or derby boot time actions consuming resources when a connection is made with
another driver
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1459
>          URL: http://issues.apache.org/jira/browse/DERBY-1459
>      Project: Derby
>         Type: Bug

>   Components: JDBC, Services
>     Versions: 10.2.0.0
>  Environment: JDK 1.6 
>     Reporter: Kathey Marsden
>     Priority: Critical
>      Fix For: 10.2.0.0
>  Attachments: autoloading_scenarios.html, bug1459_v01.diff, bug1459_v02.diff
>
> The addition of support for autoloading of Derby drivers, DERBY-930, caused two potentially
serious regresions for applications.
> 1) Early load of driver can mean that  derby system properties, such as derby.system.home
may not be processed by the driver because they are set after the driver is loaded.
> 2) Early load of the driver can mean boot time operations, such as starting network server
with derby.drda.startNetworkServer can happen even when Derby is never used if a connection
is made to another database such as Oracle.
> The attached file autoloading_scenarios.html  shows scenarios that show these regressions
plus another case that will regress if boot time operations are moved to the first Derby embedded
connection.   I don't know what solution is available that would handle all three cases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message