[DERBY-1429] Additional vulnerability to non-deterministic startup behavior when applications generate derby properties on the fly

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Duplicate
• Affects Version/s: 10.2.1.6
• Fix Version/s: 10.2.1.6
• Component/s: Services
• Assignee: Unassigned
• Reporter: Richard N. Hillegas
• Created: 19/Jun/06 21:28
• Updated: 18/Jul/06 20:50
• Resolved: 18/Jul/06 20:50

Description

JDBC4 driver-autoloading, introduced by DERBY-930, increases the exposure to non-deterministic startup behavior described in DERBY-1428. With the introduction of driver-autloading, DERBY-1428 can be triggered if OtherApp is any application which uses a JDBC driver. That is, OtherApp could use a Derby client driver, the DB2JCC driver, the Oracle client driver, etc.. The extra exposure arises because, with driver auto-loading, all JDBC drivers are registered and the Derby engine boots the first time some application asks for a Connection.

The issues are summarized in an email thread http://mail-archives.apache.org/mod_mbox/db-derby-dev/200606.mbox/browser and bug report DERBY-1399.

Workarounds are similar to those for DERBY-1428:

1) Determine the derby properties BEFORE the VM starts.

2) If that is not possible, then force the self-configuring embedded application to run first.

Issue Links

• duplicates: 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
• is related to: DERBY-1428 Multiple applications within a single jvm generating derby properties on the fly can lead to non-deterministic engine startup behavior
• relates to: DERBY-1399 DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading
• relates to: DERBY-930 Add support for autoloading of Derby client drivers