[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

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 10.2.1.6
• Fix Version/s: 10.2.1.6
• Component/s: JDBC, Services
• Environment: JDK 1.6
• Bug behavior facts: Regression
• Assignee: Richard N. Hillegas
• Reporter: Katherine Marsden
• Created: 28/Jun/06 01:21
• Updated: 30/Jun/09 15:55
• Resolved: 21/Jul/06 19:14

Description

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.

Issue Links

• is duplicated by: DERBY-1429 Additional vulnerability to non-deterministic startup behavior when applications generate derby properties on the fly
• is related to: DERBY-930 Add support for autoloading of Derby client drivers