db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Allowing Derby Network Server when Embedded Driver is not registered with Driver Manager
Date Wed, 18 May 2011 03:03:40 GMT
On 5/17/2011 6:48 PM, Ed Costello wrote:
> Hi,
>
> I've been using the Derby Embedded driver in an environment where it 
> is unsafe to have the JDBC drivers registered with 
> java.sql.DriverManager (reasons are later in this email). I'm trying 
> to use the Network Server to make these embedded databases available 
> to other processes for inspection.
>
Hi Ed,

I only skimmed at your patch but if I understand it correctly the actual 
way you are accessing the Embedded driver are not revealed in the patch 
but is implemented via the plugin point you mentioned.   I think in 
general use DriverManager has been  problematic for users and within 
Derby and now here is another case. So I think that it might be a better 
general approach to file a Jira to remove DriverManager usage from 
Network Server to avoid the OSGI conflicts you mention and then just 
remove its usage from Network Server all together.  I think it is a good 
idea to remove all internal DriverManager references if possible.  I am 
not sure how many there are left after DERBY-4664.  This may be the last 
one.

Kathey










> I've found that the Network Server doesn't work in such an environment 
> because NetworkServerControlImpl loads the embedded driver from 
> DriverManager in order to access the actual databases that it is serving.
>
> Would it be acceptable to introduce a plugin point to allow the 
> Embedded Driver to be loaded in some other fashion? I've attached a 
> patch which solves this problem for me but would like to know if this 
> is consistent with the direction of the project?
>
>
> The reason we can't use DriverManager is that we're running a OSGi / 
> J2EE hybrid environment where access to databases (and hence the 
> drivers) are managed by a particular set of services. Having these 
> drivers registered with the DriverManager breaks the ability to 
> re-start and re-deploy these bundles cleanly as it can result in 
> hanging references to the drivers. Because of this the database 
> management service explicitly clears all Drivers registered with the 
> DriverManager. There is an OSGi Service which provides equivalent 
> methods, but the static access provided by DriverManager is 
> unavailable in this environment.
>
> Thanks in Advance
> Ed
> -- 
> ------------------------------------------------------------------------
>
>
> <http://www.orionhealth.com>
> 	
>
> 	*Ed Costello **Design Engineer *
> edward.costello@orionhealth.com <mailto:edward.costello@orionhealth.com>
> P: +64 9 638 0600 Ext 3232
> F: +64 9 638 0699
> www.orionhealth.com <http://www.orionhealth.com>
>
>
>
>
> This e-mail and any attachments are intended only for the person to 
> whom it is addressed and may contain privileged, proprietary, or other 
> data protected from disclosure under applicable law. If you are not 
> the addressee or the person responsible for delivering this to the 
> addressee you are hereby notified that reading, copying or 
> distributing this transmission is prohibited. If you have received 
> this e-mail in error, please telephone us immediately and remove all 
> copies of it from your system. Thank you for your co-operation.
>
>


Mime
View raw message