[ http://issues.apache.org/jira/browse/DERBY-1459?page=all ]
Rick Hillegas updated DERBY-1459:
---------------------------------
Attachment: bug1459_v01.diff
Knut Anders made an excellent suggestion for fixing this bug: Autoload a dummy
driver which doesn't boot the engine but which indirects to the appropriate
embedded driver. I am attaching a patch which does this: bug1459_v01.diff.
Please review this approach and let me know what you think. If this seems like
a good approach, I will continue testing it.
Here is Derby's behavior under this patch:
o Instead of autoloading EmbeddedDriver, we autoload a new driver:
AutoloadedDriver.
o The DriverManager registers AutoloadedDriver rather than Driver20, Driver30,
or Driver40.
o The engine does NOT boot at autoload time.
o The engine does boot if you do the following:
1) Ask the DriverManager to connect to an embedded Derby database
or
2) Class.forName( "org.apache.derby.jdbc.EmbeddedDriver" );
or
3) Class.forName( "org.apache.derby.jdbc.EmbeddedDriver" ).newInstance();
-----------------------------------
This patch touches the following files:
M java\engine\org\apache\derby\jdbc\EmbeddedDataSource.java
Changed to indirect to the booted driver through AutoloadedDriver.
M java\engine\org\apache\derby\jdbc\EmbeddedDriver.java
Now extends AutoloadedDriver. All that remains in this class are the static
initializer and constructor needed to get the right booting behavior out of
Class.forName() and Class.forName().newInstance().
M java\engine\org\apache\derby\jdbc\Driver20.java
Changed to forward driver registration to AutoloadedDriver.
A java\engine\org\apache\derby\jdbc\AutoloadedDriver.java
New, dummy driver which holds the guts of what used to be in EmbeddedDriver.
The java.sql.Driver methods in this new class indirect to the appropriate
driver module (Driver20, Driver30, or Driver40).
M java\engine\org\apache\derby\loc\messages_en.properties
M java\shared\org\apache\derby\shared\common\reference\MessageId.java
A little tweeking of error messages.
M build.xml
Autoload directive changed to point at AutoloadedDriver rather than
EmbeddedDriver.
> 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
>
> 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
