Jean T. Anderson wrote:
Rick Hillegas wrote:
Kathey Marsden wrote:
David Van Couvering wrote:
- Log a bug
- Work on fixing it by booting on first connection rather than when
the driver is loaded.
It would be good to get input from the user community as well. One
possible approach would be to log the bug, mark it as a regression,
existing application impact, and release note needed. and have a
formal release note. Then send a note to derby-user with a pointer to
the bug and Ricks summary to see if any users feel there will be
impact. Unfortunately, my gut instinct is that this is the kind of
issue that lays dormant and then hits someone hard on upgrade or when
integrated with another product. It might broadside users
unaware, like it did the nist tests and DerbyNetAutostart tests.
It will be really helpful to have the bug and the release note to
present to users to help them understand impact.
Then we can close DERBY-930 back up too until it is decided whether
this "Heisenbug" is a show stopper or not.
I have logged two new bugs: DERBY-1428 describes the existing, pre-JDBC4
shape of the problem. DERBY-1429 describes the extra exposure introduced
by JDBC4. I have added a release note to DERBY-930, which summarizes the
problem and its workarounds. In addition, I have asked the user
community to let us know how broad the extra impact is.
Does the "precedence for properties" documentation need to be updated to
mention jdbc 4/jdk 1.6 behavior?
http://db.apache.org/derby/docs/dev/tuning/ctunsetprop23308.html
-jean
Hi Jean,
I don't see that the precedence of properties has changed. What has
changed is when we read properties during the lifetime of a vm.
Driver-autoloading does require many other edits to the user guides.
They are summarized in DERBY-1271.
Regards,
-Rick
