Rick Hillegas wrote: > Dear Derby users, > > I would like to understand if anyone thinks that they might be affected > by the following issue. This issue affects customers who do the following: > > o Run an embedded Derby application which generates its own Derby > properties on the fly. > > o In the same VM, run other JDBC applications. These other applications > could request Connections to DB2, Oracle, Derby, or any other database. > > In general, we recommend against generating Derby properties on the fly.
Where do we recommend against this? We document precedence of properties at http://db.apache.org/derby/docs/dev/tuning/ctunsetprop23308.html and also how to protect database-wide properties at http://db.apache.org/derby/docs/dev/tuning/ctunsetprop824533.html . I'm not spotting any general recommendation against setting Derby properties programmatically, though it might be there. If so, we might want to promote that recommendation in more places. -jean > This general problem is described in DERBY-1428. However, the Derby > mainline (slated to become release 10.2) expands this problem, as > described in DERBY-1429. For a workaround, see the Release Note attached > to DERBY-930. > > Here is more detail on this issue: > > a) With JDBC4, vendors mark their jar files to indicate the names of > jdbc drivers in those jars. During the lifetime of a vm, the very first > request for a Connection causes the DriverManager to look inside all of > the jars and register all indicated jdbc drivers. > > b) When our embedded driver registers itself, it also boots the engine, > using whatever derby properties are currently visible. Typically, the > engine stays booted for the lifetime of the vm. > > This can cause a Heisenbug in the following scenario: > > o The customer runs two applications in the same vm: EmbeddedApp and > OtherApp. > > o Before getting its first Connection, the EmbeddedApp hand-crafts its > own derby properties to configure the engine's behavior. > > o OtherApp could be an application which uses the Derby client driver or > some other jdbc driver. > > o If OtherApp runs before EmbeddedApp, then the engine will boot without > the hand-crafted properties. > > o It may not be deterministic whether OtherApp or EmbeddedApp runs > first. Sometimes you get the right engine properties and sometimes you > don't. > > It is worth pointing out that this Heisenbug can occur today, pre-JDBC4, > if OtherApp is another embedded Derby application. > JDBC4-driver-autoloading broadens the family of affected scenarios. > > I would like to understand how much the family is broadened. Please let > me know if you think this problem will affect you. > > Thanks, > -Rick > >
