geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder (JIRA)" <...@geronimo.apache.org>
Subject [jira] Updated: (GERONIMO-453) DerbySystemGBean doesn't call System.gc() in doStop() and soFail() as recommended in the Derby doco
Date Sat, 27 Aug 2005 23:06:05 GMT
     [ http://issues.apache.org/jira/browse/GERONIMO-453?page=all ]

Aaron Mulder updated GERONIMO-453:
----------------------------------

    Fix Version: 1.0-M5
    Description: 
The Derby doco in the section "Shutting Down the System" at http://incubator.apache.org/derby/manuals/develop/develop12.html
says the following:

    Typically, an application using an embedded Derby engine shuts down Derby just before
shutting itself down.
    However, an application can shut down Derby and later restart it in the same JVM session.

    To restart Derby successfully, the JVM needs to unload org.apache.derby.jdbc.EmbeddedDriver,

    so that it can reload it when it restarts Derby. (Loading the local driver starts Derby.)

    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.

Anyone have any objections to the recommendation of calling System.gc()?



  was:
The Derby doco in the section "Shutting Down the System" at http://incubator.apache.org/derby/manuals/develop/develop12.html
says the following:

    Typically, an application using an embedded Derby engine shuts down Derby just before
shutting itself down.
    However, an application can shut down Derby and later restart it in the same JVM session.

    To restart Derby successfully, the JVM needs to unload org.apache.derby.jdbc.EmbeddedDriver,

    so that it can reload it when it restarts Derby. (Loading the local driver starts Derby.)

    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.

Anyone have any objections to the recommendation of calling System.gc()?



        Version: 1.0-M4
    Environment: 

Are you suggesting we call System.gc() in the doStop of the DerbySystemGBean?

> DerbySystemGBean doesn't call System.gc() in doStop() and soFail() as recommended in
the Derby doco
> ---------------------------------------------------------------------------------------------------
>
>          Key: GERONIMO-453
>          URL: http://issues.apache.org/jira/browse/GERONIMO-453
>      Project: Geronimo
>         Type: Bug
>     Versions: 1.0-M4
>     Reporter: John Sisson
>     Assignee: John Sisson
>      Fix For: 1.0-M5

>
> The Derby doco in the section "Shutting Down the System" at http://incubator.apache.org/derby/manuals/develop/develop12.html
says the following:
>     Typically, an application using an embedded Derby engine shuts down Derby just before
shutting itself down.
>     However, an application can shut down Derby and later restart it in the same JVM
session. 
>     To restart Derby successfully, the JVM needs to unload org.apache.derby.jdbc.EmbeddedDriver,

>     so that it can reload it when it restarts Derby. (Loading the local driver starts
Derby.)
>     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.
> Anyone have any objections to the recommendation of calling System.gc()?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message