db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Driver autoloading and engine booting
Date Tue, 20 Jun 2006 19:29:02 GMT
Kathey Marsden <kmarsdenderby@sbcglobal.net> writes:

> Olav Sandstaa wrote:
>> Kathey Marsden wrote:
>>> 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.
> Generally it would be great if
> 1) Autoloading  (getting a connection a connection on another product)
> just registers the driver.
> 2)  Derby would boot on any of the following events.
>    - Get a Derby connection.
>    - Class.forName(...EmbeddedDriver)
>     - Class.forName(...EmbeddedDriver).newInstance()
> Is that possible?

It is not possible to ensure that Class.forName() boots the engine (it
only returns the Class object if the class already is loaded; this is
why newInstance() is needed to reload Derby after a full shutdown),
but with getConnection() and newInstance() it is possible.

Since our documentation already says that newInstance() should be
used, what about
  - Autoloading and Class.forName() register the driver
  - Class.forName().newInstance() and DriverManager.getConnection()
    boot the engine

Not an ideal solution, but it is at least deterministic when the
engine is booted. That is, if the autoloading doesn't do newInstance()
internally, in which case we're back to square one...

One alternative solution that could be explored, is loading another
driver than EmbeddedDriver in the autoloading. For instance, we could
have an EmbeddedDummyDriver which is picked up by the autoloading and
is only registered. Then Class.forName("EmbeddedDriver")
(newInstance() not needed since the class is not loaded yet) or
getConnection() would cause the engine to be booted. If this is
possible, existing applications would have the exact same behaviour as

Knut Anders

View raw message