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-930) Add support for autoloading of Derby client drivers
Date Mon, 19 Jun 2006 16:07:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-930?page=comments#action_12416781 ] 

Rick Hillegas commented on DERBY-930:
-------------------------------------

Here is a second rev of the release note. This attempts to clarify the extra exposure introduced
by jdk1.6.

PROBLEM

If an embedded Derby application generates its own Derby properties on the fly, and that Derby
application runs in the same 1.6 VM with other JDBC applications, then you are not guaranteed
that the Derby engine will pick up the custom properties when it boots.


SYMPTOM

Derby startup behavior will be non-deterministic. Sometimes the engine will pick up the custom
properties and sometimes it won't.


CAUSE

JDBC4 introduced driver-autoloading. This causes all JDBC drivers visible to the 1.6 VM to
register themselves the first time some application requests a Connection. When the embedded
Derby driver registers itself, it also boots the Derby engine and the engine picks up whatever
Derby properties are currently visible. An embedded Derby application may want to configure
the engine properties before asking for a Connection. That embedded Derby application will
not get a chance to configure engine properties if some other JDBC application in the same
1.6 VM runs first and requests a Connection. Two related bugs describe this issue in greater
detail: DERBY-1428 and DERBY-1429. DERBY-1428 affects existing customer installations running
old versions of Derby on the 1.3, 1.4, and 1.5 VMs. DERBY-1429 describes the extra exposure
introduced with the 1.6 VM.


SOLUTION

There is no general solution to the problem. If two self-configuring embedded Derby applications
run in the same VM, then only one of them can win.


WORKAROUND

The following workarounds may be useful:

1) Don't configure Derby properties inside your applications. Instead, specify Derby properties
either on the VM startup line or in a $DERBY_HOME/derby.properties which remains constant
for the VM's lifetime.

2) Don't run on the 1.6 VM. This eliminates the problem provided that you are not running
more than one embedded Derby application in the same VM.

3) If (1) and (2) are not possible, then make the self-configuring Derby application run first.


> Add support for autoloading of Derby client drivers
> ---------------------------------------------------
>
>          Key: DERBY-930
>          URL: http://issues.apache.org/jira/browse/DERBY-930
>      Project: Derby
>         Type: New Feature

>   Components: Build tools, JDBC
>     Reporter: Rick Hillegas
>     Assignee: Rick Hillegas
>      Fix For: 10.2.0.0
>  Attachments: ClassloadingTest.jar, bug930.diff, bug930_problem.diff, bug930_problem2.diff,
bug930_rev2.diff, bug930_rev3.diff
>
> Write Derby's driver names into the correct spot in derby.jar and derbyclient.jar so
that the 1.6 vm autoloads Derby drivers. Section 10.2.1 of the JDBC4 spec describes the details.

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