You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Ed Costello <ed...@orionhealth.com> on 2011/05/18 03:48:46 UTC

Allowing Derby Network Server when Embedded Driver is not registered with Driver Manager

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.

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

________________________________________________________________________

                                    
                                    
                                    
                           Ed Costello Design
                               Engineer 
                    edward.costello@orionhealth.com
                         P: +64 9 638 0600 Ext
                                  3232
                           F: +64 9 638 0699
                          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.



Re: Allowing Derby Network Server when Embedded Driver is not registered with Driver Manager

Posted by Ed Costello <ed...@orionhealth.com>.
Thanks a lot for the reply, I had assumed that the indirection through
DriverManager was deliberate so left it as is.

I've now raised https://issues.apache.org/jira/browse/DERBY-5239 with a
patch that simply replaces these usages with direct usage of the
embedded driver.

Cheers
Ed

-----Original Message-----
From: Kathey Marsden <km...@sbcglobal.net>
To: derby-dev@db.apache.org
Cc: Ed Costello <ed...@orionhealth.com>
Subject: Re: Allowing Derby Network Server when Embedded Driver is not
registered with Driver Manager
Date: Tue, 17 May 2011 20:03:40 -0700

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
> -- 
> 
> ______________________________________________________________________
> 
> 
>                                    
>                                    
>                                    
>                                    
>                           Ed Costello Design
>                               Engineer 
>                    edward.costello@orionhealth.com
>                         P: +64 9 638 0600 Ext
>                                  3232
>                           F: +64 9 638 0699
>                          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.
> 
> 
> 



-- 

________________________________________________________________________

                                    
                                    
                                    
                           Ed Costello Design
                               Engineer 
                    edward.costello@orionhealth.com
                         P: +64 9 638 0600 Ext
                                  3232
                           F: +64 9 638 0699
                          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.



Re: Allowing Derby Network Server when Embedded Driver is not registered with Driver Manager

Posted by Kathey Marsden <km...@sbcglobal.net>.
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 <ma...@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.
>
>