db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Driver autoloading and engine booting
Date Mon, 19 Jun 2006 19:47:55 GMT
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.


Mime
View raw message