Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44941956.3050405@sbcglobal.net>
Date: Sat, 17 Jun 2006 08:01:42 -0700
From: Kathey Marsden <kmarsdenderby@sbcglobal.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.13) Gecko/20060414
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Driver autoloading and engine booting
References: <44933535.8050801@sun.com> <449336BF.8060300@sun.com>
In-Reply-To: <449336BF.8060300@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

> -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.

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.

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.

Kathey


Kathey