[ http://issues.apache.org/jira/browse/DERBY-1459?page=all ]

Rick Hillegas updated DERBY-1459:
---------------------------------

    Attachment: bug1459_v04.diff

Attaching bug1159_v04.diff. This rev of the patch makes the following changes:

1) Adds a unit test (AutoloadBooting) to verify Kathey's scenarios.

2) Makes some changes to AutoloadedDriver.acceptsURL() and 
AutoloadedDriver.connect() so that the DriverManager will not accidentally boot 
Derby while trying to connect through another driver. The problem is that when 
an application requests a Connection, the DriverManager will walk through all 
loaded drivers, passing the request on to each in turn. Depending on where your 
autoloaded driver sits in the list, this may trigger an attempt to connect 
through your driver.


> 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, 
> bug1459_v03.diff, bug1459_v04.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

Reply via email to