db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1429) Additional vulnerability to non-deterministic startup behavior when applications generate derby properties on the fly
Date Mon, 19 Jun 2006 15:28:32 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1429?page=comments#action_12416778 ] 

Rick Hillegas commented on DERBY-1429:
--------------------------------------

We could separate out the booting of the engine from the registration of the embedded driver.
This would eliminate this bug in the case that there is only one embedded Derby application
in the VM.

However, we can't solve the general problem of two self-configuring Derby applications running
in the same VM. Only one of them can win. The user guide needs to strongly recommend that
application designers avoid generating Derby properties on the fly.

> 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: Store
>     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


Mime
View raw message