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
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.