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.
Attachments
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
- Closed
- 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
- Open
- relates to
-
DERBY-1399 DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading
- Closed
-
DERBY-930 Add support for autoloading of Derby client drivers
- Closed