Kathey Marsden wrote:
Rick Hillegas wrote:
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?
I think the scope of the problem is beyond generating derby.properties
on the fly.
I think the greater risk is anyone setting system properties to affect
derby behaviour. The biggest trouble maker I am guessing would be
derby.system.home.
The new requirement (I think) is that you set derby.system.home before
any driver is autoloaded and would have the symptoms described in this
mail.
Is that description correct?
http://www.nabble.com/Re%3A--jira--Commented%3A-%28DERBY-930%29-Add-support-for-autoloading-of-Derby-client-drivers-p4909085.html
I find it not uncommon to see code like this:
System.setProperty("derby.system.home", MY_DERBY_DIR);
Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance();
You are right, that there are multiple ways to get to the bug. One way
is to regenerate derby.properties itself in the directory indicated by
derby.system.home. Another way to trigger the behavior is to reset the
value of derby.system.home so that it points to a directory with a
different derby.properties. I defer to your experience as to which of
these is the more travelled route.
If I understand the problem correctly, this will no longer reliably
work if any other code in the same JVM (or is it classloader
context?) makes a database connection to any database.
Is that correct?
Right. It does not reliably work today if the VM runs more than one
embedded derby application, one of which is self-configuring. That's bug
DERBY-1428. JDBC4 introduces a new scenario for the bug, as you
describe: the bug can turn up if jdk1.6 runs a self-configuring Derby
application together with another application, which connects to some
database. That's DERBY-1429.
The point of seeing if we can keep the tests the same is to see if we
can avoid user impact. We should olnly change the tests if and when
we decide the behavior change is ok. If later we add better tests
that more accurately reflect actual user scemarios like the one above
instead, that would be great, but the bottom line is just like the
tests, USERS DO STRANGE THINGS and expect things to still work. If
they upgrade and things suddenly don't work, they want the old
behaviour back and we can't give it to them because new users depend
on the new behaviour. We trap ourselves into a very ugly corner.and
this is a very bad and messy thing. It is better to keep things
working if we can. Every time we change a test to adapt to some new
usage requirement it should be a huge red flag that someone is going
to hit the problem.
Kathey
Thanks for the explanation. I'm looking forward to your analysis and to
more feedback from the user community so that we can decide what to do here.
