Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1636548061.1249659794937.JavaMail.jira@brutus>
Date: Fri, 7 Aug 2009 08:43:14 -0700 (PDT)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Issue Comment Edited: (DERBY-700) Derby does not prevent
 dual boot of database from different classloaders on Linux and Mac OS X
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


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

Rick Hillegas edited comment on DERBY-700 at 8/7/09 8:41 AM:
-------------------------------------------------------------

I have confirmed the following with Alan Bateman, the spec lead for NIO2:

1) The call we are making (java.nio.channels.FileChannel.tryLock) is supposed to raise java.nio.channels.OverlappingFileLockException if an attempt is made to lock the same section of a file twice in the same VM, regardless of what ClassLoaders the calls come from. So the results I reported are expected.

2) However, in Java 5 java.nio.channels.OverlappingFileLockException is NOT raised in this situation. This is a Java 5 bug. The bug was fixed in Java 6.

3) Alan is not aware of any changes made by IBM to the nio code in this area. He is curious about the claim that java.nio.channels.OverlappingFileLockException is not raised by IBM Java 6 on SuSE Linux.

Could someone run the repro on IBM Java 6 on SuSE Linux in order to resolve this confusion?

One more wrinkle: When (2) was fixed, a compatibility flag was introduced so that people could continue to enjoy the old behavior, that is, the behavior we don't want. You will get the bad Java 5 behavior if you set the following system property to anything other than false:

   sun.nio.ch.disableSystemWideOverlappingFileLockCheck	


Thanks,
-Rick

      was (Author: rhillegas):
    I have confirmed the following with Alan Bateman, the spec lead for NIO2:

1) The call we are making (java.nio.channels.FileChannel.tryLock) is supposed to raise java.nio.channels.OverlappingFileLockException if an attempt is made to lock the same section of a file twice in the same VM, regardless of what ClassLoaders the calls come from. So the results I reported are expected.

2) However, in Java 5 java.nio.channels.OverlappingFileLockException is NOT raised in this situation. This is a Java 5 bug. The bug was fixed in Java 6.

3) Alan is not aware of any changes made by IBM to the nio code in this area. He is curious about the claim that java.nio.channels.OverlappingFileLockException is not raised by IBM Java 6 on SuSE Linux.

Could someone run the repro on IBM Java 6 on SuSE Linux in order to resolve this confusion?

One more wrinkle: When (2) was fixed, a compatibility flag was introduced so that people could continue to enjoy the old behavior, that is, the behavior we don't want. You will get the bad Java 5 behavior if you set the following system property to anything other than true:

   sun.nio.ch.disableSystemWideOverlappingFileLockCheck	


Thanks,
-Rick
  
> Derby does not prevent dual boot of database from different classloaders on Linux and Mac OS X
> ----------------------------------------------------------------------------------------------
>
>                 Key: DERBY-700
>                 URL: https://issues.apache.org/jira/browse/DERBY-700
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.4.1.3
>         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)
> also
> java version "1.5.0_19"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-b02-304)
> Java HotSpot(TM) Client VM (build 1.5.0_19-137, mixed mode, sharing)
> on Mac OS X 10.5.7.
>            Reporter: Kathey Marsden
>            Priority: Critical
>         Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, derby-700_06_19_2007, derby-700_diff.txt, derby-700_stat.txt, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff, DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat, derby-700_with_NPE_fix_diff.txt, derby-700_with_NPE_fix_stat.txt, derby.log, derby700_singleproperty_v1.diff, derby700_singleproperty_v1.stat, DualBootRepro.java, DualBootRepro.java, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> Derby does not prevent dual boot from two different classloaders on Linux and Mac OS X.
> 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.
-
You can reply to this email to add a comment to the issue online.