Rick Hillegas wrote:
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. 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.
I think DERBY-1428 and DERBY-149 are not really related to generating
derby.properties on the fly they are related to when Derby boots and
when derby.system.home is recognized. derby.system.home *has* to be set
with a system property. Anyone who sets derby.system.home or static
derby properties programatically with System.setProperty() may be
affected if they do not have control over their calling context.
Another driver might cause derby to be autoloaded before these
properties are set. Perhaps these issues would be better worded as:
"Derby can have non-deterministic behaviour when derby.system.home or
other static properties are set with System.setProperty()"
More common reported symptoms will likely be after upgrading to
Derby 10.2 and JDK 1.6 users will report the following systems because
derby.system.home is not picked up properly.
- I get XJ004.C=Database ''...'' not found. (Derby is looking in the
wrong place for the db)
- There is nothing in my database. (create=true was on
the url and so app created a new db in the wrong place)
- My database was created in the wrong place.
- Properties set in derby.properties are not being picked up.
Some more info:
http://www.nabble.com/Re%3A--jira--Commented%3A-%28DERBY-930%29-Add-support-for-autoloading-of-Derby-client-drivers-p4909085.html
Kathey
