Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Tue, 20 Jun 2006 12:29:03 -0700
From: Rick Hillegas <Richard.Hillegas@Sun.COM>
Subject: Re: Driver autoloading and engine booting
In-reply-to: <4498392B.9010901@sbcglobal.net>
Sender: Richard.Hillegas@Sun.COM
To: derby-dev@db.apache.org
Message-id: <44984C7F.6080701@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <44933535.8050801@sun.com> <449336BF.8060300@sun.com>
 <44941956.3050405@sbcglobal.net> <4498226D.3080702@sun.com>
 <4498392B.9010901@sbcglobal.net>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

Kathey Marsden wrote:

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

I think we could satisfy the first and third bullets under (2). I don't 
think we can satisfy the second bullet. Here's the contract from 
http://download.java.net/jdk6/doc/api/index.html:

"When a Driver class is loaded, it should create an instance of itself 
and register it with the DriverManager. This means that a user can load 
and register a driver by calling

   |Class.forName("foo.bah.Driver")"

| 

I believe that you want the Derby engine to boot when the embedded 
driver class is loaded into the VM. That's your second bullet under (2). 
This will trigger the autoloading problem. With autoloading, you no 
longer have control over when the embedded driver class is loaded into 
the VM. This is what happens with autoloading:

a) Some application in the VM requests a Connection via 
DriverManager.getConnection()
b) This causes DriverManager to look inside every jar file on the 
classpath hunting for the names of jdbc drivers
c) The DriverManager then calls Class.forName() on each of those drivers
d) This causes each driver to register a new instance of itself with the 
DriverManager

To fix the autoloading problem, we would have to stop Derby from booting 
at the following event:

   - Class.forName(...EmbeddedDriver)

In addition, the embedded driver would need a new constructor which 
doesn't boot the engine. That constructor would be called at 
classloading time to make the instance which is registered with 
DriverManager. The existing no-arg constructor would have to continue 
booting Derby so that existing applications could continue to 
resuscitate the engine as follows:

   - Class.forName(...EmbeddedDriver).newInstance() 

Regards,
-Rick


>
> That way DerbyNetAutostart would still be AOK (I think)  as it:
> 1. Load the client driver: TestUtil.loadDriver()
>
> 2. set derby.drda.startNetworkServer=true
>
> 3. Load the embedded driver: 
> Class.forName("...EmbeddeDriver).newInstance()
>
> Kathey
>
>
>