db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3612) Developer's Guide needs correction on garbage collection
Date Tue, 10 Jun 2008 12:22:45 GMT

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

Knut Anders Hatlen commented on DERBY-3612:
-------------------------------------------

Kim, the patch looks like an improvement to me, so +1 to commit.

I don't have any definite answers to your questions, but I have some
more background information:

Classes are not unloaded until their class loader is eligible for
garbage collection[1]. If the driver class was loaded in the system
class loader, it'll probably stay alive until the JVM is terminated.

Since Class.forName("...EmbeddedDriver") only performs work if the
EmbeddedDriver class is not loaded, many of the examples in the
documentation additionally use a call to newInstance() to ensure that
the initialization is performed in the cases where the driver has been
loaded previously in the same JVM instance, the engine has been shut
down, but the driver class has not been unloaded. See also this[2]
discussion and DERBY-503, which was logged in order to make the
documentation state explicitly that newInstance() is recommended when
(re)loading the driver.

When Martin tested the shutdown behaviour, he used the ij tool and the
SimpleApp demo. Both of these loaded the driver with Class.forName() +
newInstance(), so it didn't matter whether or not the driver class was
unloaded. I wrote a simple test myself which only executed the
following code twice in the same JVM:

        Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
        try {
            DriverManager.getConnection("jdbc:derby:;shutdown=true");
        } catch (SQLException e) {
            // XJ015 is the expected system shutdown exception
            if (!"XJ015".equals(e.getSQLState())) {
                throw e;
            }
        }

Note that I didn't call newInstance().

The second time it was executed, it threw this exception:

Exception in thread "main" java.sql.SQLException: org.apache.derby.jdbc.EmbeddedDriver is
not registered with the JDBC driver manager
        at org.apache.derby.jdbc.AutoloadedDriver.getDriverModule(Unknown Source)
        at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
        at java.sql.DriverManager.getConnection(DriverManager.java:582)
        at java.sql.DriverManager.getConnection(DriverManager.java:207)
        at ReloadDriver.main(ReloadDriver.java:15)

If the code used Class.forName(...).newInstance() the second time it
loaded the class, it didn't throw an exception. Calling System.gc()
between the shutdown and the reloading wouldn't make any difference,
since the driver class wasn't eligible for garbage collection.

In fact, I think mentioning garbage collection of classes when
documenting engine shutdown is more confusing than enlightening,
especially given that (a) classes are not collected until their class
loader is, and (b) System.gc() doesn't give any guarantees. Since the
only robust solution is to call newInstance() when reloading the
driver, I think it's better to document that and not mention the
garbage collector at all.

[1] http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.7
[2] http://www.nabble.com/derby-jdbc-load-driver-to577168.html

> Developer's Guide needs correction on garbage collection
> --------------------------------------------------------
>
>                 Key: DERBY-3612
>                 URL: https://issues.apache.org/jira/browse/DERBY-3612
>             Project: Derby
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 10.3.2.1
>            Reporter: Kim Haase
>            Assignee: Kim Haase
>            Priority: Minor
>         Attachments: DERBY-3612.diff, tdevdvlp20349.html
>
>
> In a comment on DERBY-3585, Martin Zaun pointed out the following error:
> devguide/tdevdvlp20349.dita
>    - found a flatly wrong statement but did NOT correct here since
>      unrelated to server shutdown authentication:
>      "You cannot explicitly request that the JVM unload a class, but you
>      can ensure that the EmbeddedDriver class is unloaded by using a
>      System.gc() to force it to garbage collect classes that are no longer
>      needed. Running with -nogc or -noclassgc definitely prevents the class
>      from being unloaded and makes you unable to restart Derby in the same
>      JVM."
>      System.gc() is only a suggestion to the Runtime to garbage-collect, it
>      cannot be enforced, and there's no guarantee whatsoever that GC has
>      run and any classes been unloaded. Likewise it's most probably not
>      guarantueed that -nogc or -noclassgc definitely (!) prevent a class
>      from being unloaded (a JVM may ignore these options...) 
> This needs to be fixed. Thanks, Martin.
> One more question: are -nogc and -noclassgc java command line options, or options to
some other command? I can't find them in the java command documentation -- http://java.sun.com/javase/6/docs/technotes/tools/windows/java.html.
There is an -Xnoclassgc option, however.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message