[ http://issues.apache.org/jira/browse/DERBY-1429?page=all ]
Mike Matrigali updated DERBY-1429:
----------------------------------
Component: Services
(was: Store)
This issue should be handled by the monitor, not the store.
> Additional vulnerability to non-deterministic startup behavior when
> applications generate derby properties on the fly
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1429
> URL: http://issues.apache.org/jira/browse/DERBY-1429
> Project: Derby
> Type: Bug
> Components: Services
> Versions: 10.2.0.0
> Reporter: Rick Hillegas
>
> 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.
--
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
