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.
-1 on removing the autoloading feature, unless people have evidence
that this is going to cause real problems for our users.
I'll analyze some usage scenarios that I am aware of and see what the
impact might be. The most important thing is that this be a
deliberate choice and that we not rush new functionality and
introduce a regression where there is a reasonable technical
alternative, where we can have autoloading and avoid the regression.
Thanks. Your analysis will be very helpful.
I also have a couple of questions:
1) How much work is it and what are the risks to moving the boot to
the first connection ?
2) What are the implications to derby.drdra.startNetworkServer with
the DERBY-930 change. Olav mentioned that even if the boot was moved,
DerbyNetAutostart would still need to be changed.
3) If derby booted at the first connection or the first instantiation
of the driver (whichever came first) , would that solve the
derby.drda.startNetworkServer problem.
Hi Olav, could you address these questions?
If we could get DerbyNetAutoStart running without changes and nist put
back the way it was, I think we would be ok.
The fact that these tests require changes after DERBY-930 is a good
indicator that users will be impacted.
I'm afraid I don't understand why we would want to revert our tests to
the old behavior. It seems to me that our tests are practicing stunts
which we strongly discourage: changing Derby properties on the fly. In
general, there will always be Heisenbugs for applications which do this
and we should discourage this practice in the strongest possible terms.
What is the benefit of reverting the test behavior?
Thanks,
-Rick
Kathey
Kathey