db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olav Sandstaa <Olav.Sands...@Sun.COM>
Subject Re: Driver autoloading and engine booting
Date Tue, 20 Jun 2006 16:29:33 GMT
Kathey Marsden wrote:
> 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 ?

I do not know the code well enough to give a good estimate, but if I 
have to guess my estimate would be about two weeks of development plus 
test writing. In addition there might be some need to clean up some 
existing tests which were not "well behaved" or needed changes (for 
instance handling of new error situations) in this area. The risk of 
moving the boot of the engine to the first connection should not be big 
as far as I can tell.

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

The implications to derby.drda.startNetworkServer is best illustrated by 
what DerbyNetAutoStart do:

1. Load the client driver: TestUtil.loadDriver()

2. set derby.drda.startNetworkServer=true

3. Load the embedded driver: Class.forName("...EmbeddeDriver).newInstance()

Some scenarios for what happens for different solutions:

* With autoloading: This test fails with autoloading since the engine is 
booted in step 1 (as part of loading the client driver). At this point 
the derby.drda.startNetworkServer is not set and the network server will 
not be started.

* With autoloading and deferred booting of engine and network server: If 
we defer the booting of the engine and network serveruntil the first 
connection is made, this test will also fail since there are no 
connection that goes directly to the embedded driver in this test and 
neither the engine or the network server will be started. All 
connections goes to the client driver which will not be able to connect 
to the network server since it will never be started.

* With autoloading and deferred booting of engine, but not network 
server: The network server will not be started because at the time the 
driver is loaded, the derby.drda.startNetworkServer is false. The 
embedded engine will not be booted since there are no connections coming.

* Without autoloading: The test passes since at the time the embedded 
driver is loaded, the derby.drda.startNetworkServer is true and thus the 
network server is started.

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

This depends on what you mean by "the first instantiation of the 
driver". With autoloading this could be considered done as part of the 
autoloading of the driver (i.e. too early to boot the engine). It also 
depends on whether we would be able in the driver code to know that this 
was done as part of the autoloading of the driver or explicitly by the 
application code. E.g., would both of these calls:


result in Derby code being run? And would we be able to differentiate 
this from when the autoloading code loaded the driver? I do not know.

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

One comment about the changes to the Nist test. I think these are good 
and solve a problem that already was present in the test framework. When 
the a suite run with useProcess=false it sets propeties (e.g.) 
derby.system.home which the test suite relies on and then loads the 
embedded driver. With multiple test suites in derbyall running with 
useProcess=false this would make all the suite's system properties being 
ignored and all but the first suite would run with the properties set 
the by suite to run with useProcess=false (since they basically was 
using the embedded driver and engine loaded by the first suite).


View raw message