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] Created: (DERBY-1429) Additional vulnerability to non-deterministic startup behavior when applications generate derby properties on the fly
Date Mon, 19 Jun 2006 14:29:30 GMT
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