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:
Class.forName(...EmbeddedDriver)
Class.forName(...EmbeddedDriver).netInstance()
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).
Regards,
Olav
