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 16:47:15 GMT
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?


> Kathey
> Kathey

View raw message