[jira] Updated: (DERBY-1429) Additional vulnerability to non-deterministic startup behavior when applications generate derby properties on the fly
[ http://issues.apache.org/jira/browse/DERBY-1429?page=all ] Andrew McIntyre updated DERBY-1429: --- Fix Version: 10.2.0.0 > 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 > Fix For: 10.2.0.0 > > 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
[jira] Updated: (DERBY-1429) Additional vulnerability to non-deterministic startup behavior when applications generate derby properties on the fly
[ 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
