db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (DERBY-5043) Document the new url attribute deregister to keep the AutoloadedDriver registers in DriverManager
Date Wed, 02 Mar 2011 14:38:36 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001432#comment-13001432
] 

Rick Hillegas edited comment on DERBY-5043 at 3/2/11 2:37 PM:
--------------------------------------------------------------

> 2) Is this attribute valid only when using JDBC 4.0 or 4.1? (Driver autoloading is present
with JDBC 4.0 but not with 3.0.)

The attribute works if you are running on JDK 1.4 (i.e. JDBC 3.0). I don't think it is helpful
to discuss this attribute in terms of autoloading. (In any event, driver autoloading was introduced
by JDBC 3.0 although Derby didn't get around to supporting it until release 10.2.)

I think it would be better to frame the discussion in terms of the following user-visible
behaviors:

1) Driver (de)registration.

2) Orderly shutdown.

3) Garbage-collection of Derby classes.

There are several ways that the embedded driver can be registered:

i) By invoking Class.forName( "org.apache.derby.jdbc.EmbeddedDriver" ). This mechanism works
on all JVMs from JDK 1.4 on up.

ii) By setting -Djdbc.drivers=org.apache.derby.jdbc.EmbeddedDriver when booting the engine's
VM and then by calling DriverManager.getConnection(). This mechanism also works on all JVMs
from JDK 1.4 on up. It is the original version of driver autoloading.

iii) By simply calling DriverManager.getConnection(). This is the additional autoloading mechanism
which was introduced by JDBC 4.0. This scenario only works on Java 6 on up.

Once the embedded driver is registered, you can shutdown the Derby engine by using the special
shutdown URL. If you specify deregister=false at the end of that URL, then you will see the
following behavior:

a) The embedded driver will remain registered.

b) The Derby classes will NOT be garbage-collected.

c) You can get a Derby connection just by issuing a DriverManager.getConnection() call. That
is, you DON'T need to first invoke Class.forName( "org.apache.derby.jdbc.EmbeddedDriver" ).newInstance().

In contrast, if you DON'T specify deregister=false on the shutdown URL, then you will see
the opposite behavior:

a) The embedded driver will be deregistered.

b) The Derby classes will (probably, eventually) be garbage-collected.

c) You will have to invoke Class.forName( "org.apache.derby.jdbc.EmbeddedDriver" ).newInstance().
before obtaining a new Derby connection.

Hope this helps,
-Rick


      was (Author: rhillegas):
    > 2) Is this attribute valid only when using JDBC 4.0 or 4.1? (Driver autoloading is
present with JDBC 4.0 but not with 3.0.)

The attribute works if you are running on JDK 1.4 (i.e. JDBC 3.0). I don't think it is helpful
to discuss this attribute in terms of autoloading. (In any event, driver autoloading was introduced
by JDBC 3.0 although Derby didn't get around to supporting it until release 10.2.)

I think it would be better to frame the discussion in terms of the following user-visible
behaviors:

1) Driver (de)registration.

2) Orderly shutdown.

3) Garbage-collection of Derby classes.

There are several ways that the embedded driver can be registered:

i) By invoking Class.forName( "org.apache.derby.jdbc.EmbeddedDriver" ). This mechanism works
on all JVMs from JDK 1.4 on up.

ii) By setting -Djdbc.drivers=org.apache.derby.jdbc.EmbeddedDriver when booting the engine's
VM and then by calling DriverManager.getConnection(). This mechanism also works on all JVMs
from JDK 1.4 on up. It is the original version of driver autoloading.

iii) By simply calling DriverManager.getConnection(). This is the additional autoloading mechanism
which was introduced by JDBC 4.0. This scenario only works on Java 6 on up.

Once the embedded driver is registered, you can shutdown the Derby engine by using the special
shutdown URL. If you specify deregister=true at the end of that URL, then you will see the
following behavior:

a) The embedded driver will remain registered.

b) The Derby classes will NOT be garbage-collected.

c) You can get a Derby connection just by issuing a DriverManager.getConnection() call. That
is, you DON'T need to first invoke Class.forName( "org.apache.derby.jdbc.EmbeddedDriver" ).newInstance().

In contrast, if you DON'T specify deregister=true on the shutdown URL, then you will see the
opposite behavior:

a) The embedded driver will be deregistered.

b) The Derby classes will (probably, eventually) be garbage-collected.

c) You will have to invoke Class.forName( "org.apache.derby.jdbc.EmbeddedDriver" ).newInstance().
before obtaining a new Derby connection.

Hope this helps,
-Rick

  
> Document the new url attribute deregister to keep the AutoloadedDriver registers in DriverManager
> -------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5043
>                 URL: https://issues.apache.org/jira/browse/DERBY-5043
>             Project: Derby
>          Issue Type: Improvement
>          Components: Documentation
>    Affects Versions: 10.7.1.1
>            Reporter: Lily Wei
>            Assignee: Kim Haase
>              Labels: derby_triage10_8
>             Fix For: 10.8.0.0
>
>         Attachments: Repro2905.java
>
>
> With DERBY-2905, we have a new connection url attribute - deregister. After a shutdown
of the embedded driver, the AutoloadedDriver is unregistered from the DriverManager. Users
who wish to keep the AutoloadedDriver can set the deregister attribute on the connection url
to false. It is only valid with shutdown=true. And, the default behavior with shutdown=true
is deregister=true. 
> For example: 
> 'shutdown=true;deregister=true" (It is okay not to specify deregister=true)
> 'shutdown=true;deregister=false"

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message