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 "Rick Hillegas (JIRA)" <ji...@apache.org> on 2011/03/02 15:38:36 UTC

[jira] Issue Comment Edited: (DERBY-5043) Document the new url attribute deregister to keep the AutoloadedDriver registers in DriverManager

    [ 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