db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Driver autoloading and engine booting
Date Mon, 19 Jun 2006 18:59:27 GMT
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();

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?


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



Mime
View raw message