[ 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
