Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <3940312.1154532074895.JavaMail.jira@brutus>
Date: Wed, 2 Aug 2006 08:21:14 -0700 (PDT)
From: "Rick Hillegas (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-700) Derby does not prevent dual boot of
 database from different classloaders on Linux
In-Reply-To: <1202629995.1131658683294.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DERBY-700?page=comments#action_12425259 ] 
            
Rick Hillegas commented on DERBY-700:
-------------------------------------

Where can Derby store VM-global state? It has been pointed out that System properties are an awkward kind of VM-global state for the following reasons:

1) SecurityManager problems
2) Race conditions

What other VM-global state can Derby access? One Derby object that's global across the VM is the Derby driver registered with the DriverManager.

1) Could we use the registered Derby driver to anchor VM-global state?
2) Are there other VM-global Derby objects which we could use?


> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
>                 Key: DERBY-700
>                 URL: http://issues.apache.org/jira/browse/DERBY-700
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.1.2.1
>         Environment: ava -version
> java version "1.4.2_08"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)
>            Reporter: Kathey Marsden
>         Assigned To: V.Narayanan
>            Priority: Critical
>             Fix For: 10.2.0.0
>
>         Attachments: DERBY-700.diff, DERBY-700.stat, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat, DualBootRepro.java, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2
>
>
> Derby does not prevent dual boot from two different classloaders on Linux.
> To reproduce run the  program DualBootRepro with no derby jars in your classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can change the location by changing the DERBY_LIB_DIR variable.
> On Linux the output is:
> $java -cp . DualBootRepro
> Loading derby from file:10.1.2.1/derby.jar
> 10.1.2.1/derby.jar
> Booted database in loader java.net.URLClassLoader@8ed465
> FAIL: Booted database in 2nd loader java.net.URLClassLoader@dc6a77
> On Windows I get the expected output.
> $ java -cp . DualBootRepro
> Loading derby from file:10.1.2.1/derby.jar
> 10.1.2.1/derby.jar
> Booted database in loader java.net.URLClassLoader@1ac04e8
> PASS: Expected exception for dualboot:Another instance of Derby may have already booted the database D:\marsden\repro\dualboot\mydb.

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