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 "Kathey Marsden (JIRA)" <de...@db.apache.org> on 2005/11/10 22:38:03 UTC
[jira] Created: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
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
Type: Bug
Versions: 10.1.2.1
Reporter: Kathey Marsden
Fix For: 10.1.3.0
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
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740588#action_12740588 ]
Rick Hillegas commented on DERBY-700:
-------------------------------------
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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=comments#action_12424948 ]
Daniel John Debrunner commented on DERBY-700:
---------------------------------------------
Using system properties will require that every user running with the security manager grant a new permission in their policy file to allow setting these system properties. I thought an earlier discussion on the list had recommended not to use system properties this way.
One issue with system properties is that how do atomically set and get the property, I think that is needed to perform locking?
In your current patch, there is a window between where you get and set the property where another thread in a anoter class loader could
come in and "lock" the database, resulting in two active derby instances connecting to the same database.
I also don't understand why on getting the system property you are catching NullPointerException and IllegalArgumentException, how would these
be thrown by System.getProperty()?
> 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, DualBootRepro.java, DualBootRepro2.zip
>
>
> 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
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504902 ]
Daniel John Debrunner commented on DERBY-700:
---------------------------------------------
Simple question is why is a new method needed on StorageFile. Since one can already get an object to perform random access i/o on a StorageFile, why is a new method needed to perform the same functionality.
Either it is because for some reason the api requires the lock files hold different contents to the file being locked. I don't think this is the case.
Or it is because it's not needed. I think this is the case, but there must have been some reason for adding it. I'm just asking what is the reason for adding such a method.
I think we are creating a StorageFile to represent "dbex.lck" (whatever the name is) and then locking that file. That's all good, but why can we not modify that file using the existing methods on StorageFactory?
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren updated DERBY-700:
-------------------------------------
Derby Info: [Existing Application Impact, Release Note Needed] (was: [Release Note Needed, Existing Application Impact])
I am unchecking the 10.3 fixin. It doesn't look like this is going to make it.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
Kathey Marsden updated DERBY-700:
---------------------------------
Attachment: DualBootRepro2.zip
Here is an updated repro with a classloader that should not require the classpath remove other derby jars
> 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
> Type: Bug
> Components: Store
> 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
> Assignee: Suresh Thalamati
> Attachments: DualBootRepro.java, DualBootRepro2.zip
>
> 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
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-700:
---------------------------------
Derby Info: [Existing Application Impact, Release Note Needed]
Applications will need to set a new permission in their policy file. So this will affect existing applications and release note is needed.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren updated DERBY-700:
-------------------------------------
Fix Version/s: 10.3.0.0
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, 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, 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763113#action_12763113 ]
Rick Hillegas commented on DERBY-700:
-------------------------------------
Thanks Kathey and Myrna. The release note looks good and it passes the ReleaseNoteReader's checks.
> 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.1.3.3, 10.2.2.1, 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.0.0
> 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
> Assignee: Rick Hillegas
> Priority: Critical
> Fix For: 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.0.0
>
> Attachments: derby-700-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, derby-700-02-aa-testCleanup.diff, 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, 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.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-700:
---------------------------------
Here is a description of a possible solution - any feedback is appreciated:
I would like to see some solution to DERBY-700 go into the 10.3 release, as it is too easy currently for users to access their same database from 2 different classloaders in the same JVM and corrupt their database.
Let me try to explain the problem again. Derby protects multiple thread
access to databases using in memory locking. Any situation where 2 instances of Derby can access the same on disk database but not coordinate through the same in-memory locking scheme creates a situation
that can lead to log/data corruption.
Derby coordinates access to an ondisk database using a 2 level per db
locking scheme. The following is high level and probably misses some
detail.
1) first it obtains what I refer to as an OS file lock, this is not a java defined mechanism. It depends on an OS specific behavior that it
is not possible to delete a file on some OS's if the file is still open
(the most common OS where this is true are I believe all window's
OS's 98, NT, 2000, xp, ...).
A) If lock file does not exist we open it and leave it open --> lock granted
B) If lock file does exist we try to delete it, if we can then
we go back to A. If we can't we assume file is locked and
give up.
2) The second level is that we use java base file locking. This only
became available in 1.4.2 and later jvm's. This does standard locking and automatically takes care of releasing lock if JVM goes
away.
We kept both steps, even though it seems that step 2 is sufficient to
provide backward compatible protection. So anyone running on a JVM
prior to 1.4.2 on a windows platform would still be protected. The
pre-derby code base also had to worry about protecting access against
versions of the code that did not have step 2 implemented.
The problem is that in cases where derby is run in 2 class loaders in
the same jvm the step 2 file locking does not work. It is meant only
to protect threads in different JVMS, so it provides no help in preventing access from 2 different class loaders in the same JVM. It
turns out that step 1 on windows system solves the locking problem
on windows systems for multiple class loaders also.
So a solution should provide 2 things:
1) prevent access from another classloader in the same JVM
2) not allow false positives. So for instance a standard "lock file" could be used on unix systems, creating it and when one boots check
for existence of the lock file and give up if it exists. The problem
is that it is very easy to cause a JVM to exit without properly cleaning
the lock file and thus one would get into situation where user may have
to clean lock files by hand.
Here is my current proposal, but I really don't like it -- I am hoping someone out there can come up with something better.
o keep the step 1 and step 2 locking as described above. It solves cross JVM locking completely.
o create a step 3 locking step, the only purpose is to recognize situations step 1 and 2 can't.
o use simple file system lock file to implement step 3 locking:
A) on db boot if no lock file exists, create it and put a timestamp in the file. This db boot is responsible for updating that timestamp
every N seconds, for this we need to come up with a guaranteed executing background thread - there are known problems with current background thread, and long checkpoints for instance. On shutdown of db we delete lock file.
B) on db boot if lock file exists we open it, and get the timestamp and compare it with the current timestamp. If the difference is greater
than N we assume the lock file has been left around incorrectly and we
delete the file and go to A (or just open it and update it with our
current timestamp). It probably is worth logging this event in derby.log.
One nice thing about the above solution is that I think it also solves
our problem with muliple machines accessing the same disk (as long as
their timestamps are the same or close). I think we can pick a large N
as this should be an error case (ie. the purpose of N is to catch the
case where a classloader went away without allowing us to clean up - I don't know classloader stuff to know how likely this is), but it is probably worth making it
configurable so we could adjust in the field if necessary.
I really don't like forcing Derby to run a job every N seconds. It could be hard to explain to users why derby is doing work every N
seconds even when nothing else is happening. I worked on a different
product a long time ago that required us to maintain our own timer for use in scheduling waits and users noticed and complained such that we
had to add a backoff mechanism based on the amount of work being done
just so the process would not show up at a steady 1% (or whatever) on
there process status monitors. Now that timer was a lot shorter than
seconds so it may not be an issue.
Some extensions I considered:
1) come up with a unique ID that is specific to a JVM and can be queried by any thread in any classloader in the JVM. If we had that then we could write that value into the step 3 lock file and we know that if we
opened the file and saw a different ID, the lock file was invalid. If
we did this then we narrow the chance of a false positive but we eliminate the chance to catch cross machine access.
2) Have the opener db log some unique id specific to it in addition to the timestamp, maybe this is just the first timestamp of the open. Then it could at least tell the next time if another
class loader had incorrectly started, and throw/log some error so we
could catch this problem.
3) maybe the value of N should be logged in the file, I think it has to
be if we allow it to be configurable.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Priority: Critical
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744557#action_12744557 ]
Rick Hillegas commented on DERBY-700:
-------------------------------------
Ported 805448 from trunk to 10.5 branch at subversion revision 805454.
> 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-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744479#action_12744479 ]
Rick Hillegas commented on DERBY-700:
-------------------------------------
The tests ran cleanly for me except for an error in ManagementMBeanTest. I ran the test by itself and it passed cleanly. I doubt that this fix affected that test. Here is the error:
1) testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError: expected:<2> but was:<8>
at org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.startStopManagement(ManagementMBeanTest.java:86)
at org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.testStartStopManagementFromApplication(ManagementMBeanTest.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 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-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, 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.
[jira] Resolved: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas resolved DERBY-700.
---------------------------------
Resolution: Fixed
Issue & fix info: [High Value Fix] (was: [Patch Available, High Value Fix])
Resolving this issue. It looks like the noise in ManagementMBeanTest has been cleaned up.
> 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
> Assignee: Rick Hillegas
> Priority: Critical
> Attachments: derby-700-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, derby-700-02-aa-testCleanup.diff, 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.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-700:
---------------------------------
Attachment: releaseNote.html
release note
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740635#action_12740635 ]
Rick Hillegas commented on DERBY-700:
-------------------------------------
Hi Kathey. The bug id is 6332756. See http://forums.sun.com/thread.jspa?threadID=5321079
> 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740641#action_12740641 ]
Kathey Marsden commented on DERBY-700:
--------------------------------------
Thanks Rick for the reference. Was there consideration given to bakcporting the fix to 1.5, perhaps even with a different default for sun.nio.ch.disableSystemWideOverlappingFileLockCheck?
The bug comments say "Fixing this issue is straight-forward but it introduces a behaviour change". At least having the property available in 1.5 to force the check would be helpful to eliminate the possibility of dual boot from corruption cases.
> 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.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-700:
--------------------------------
Attachment: derby-700-01-ab-catchOverlappingFileLockException.diff
Attaching derby-700-01-ab-catchOverlappingFileLockException.diff. This adds the comment which Mike recommended and adds a test culled from one of the previous patches. I will run regression tests again.
Touches the following files:
M java/engine/org/apache/derby/impl/io/DirFile4.java
Graceful handling of OverlappingFileLockException.
M java/testing/org/apache/derbyTesting/functionTests/tests/store/_Suite.java
A java/testing/org/apache/derbyTesting/functionTests/tests/store/ClassLoaderBootTest.java
M java/testing/org/apache/derbyTesting/junit/JDBC.java
Two test cases. One runs in all environments and checks that anyone can boot a database that has been shut down already. The other test case verifies that a database can't be booted twice if the VM is at Java 6 or higher.
> 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-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, 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.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-700:
---------------------------------
Derby Categories: [Data corruption, High Value Fix] (was: [High Value Fix])
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> 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)
> 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503967 ]
Daniel John Debrunner commented on DERBY-700:
---------------------------------------------
>From a very quick look at the code two things jumped out at me:
1) Why does the test need a Derby specific class loader? The upgrade tests don't and there are performing the same style of operation.
2) The new method StorageFile.getLockedFile() is part of the api so its definition needs to be clear.
2a) In the interface it says it returns the file for the lock file, but I don't think lock file is defined anywhere in the interface description.
2b) The interface doesn't indicate it can return null, but one implementation of it does.
2c) Why is this method on StorageFile, it's not an attribute of a specific file, at least I don;t think it is. Is there a lock file per open file?
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Suresh Thalamati (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482927 ]
Suresh Thalamati commented on DERBY-700:
----------------------------------------
I took a quick looks at fixes for LUCENE-305 and LUCENE-635 , which are fixed now. I did not see any code that is attempting to solve locking within a jvm across class loaders boundaries. May be I am missing something !
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Priority: Critical
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740669#action_12740669 ]
Kathey Marsden commented on DERBY-700:
--------------------------------------
If for 1.5 the property default is the current bad behavior, I think there would be no compatibility concern and it would provide a worthwhile supportability improvement especially if it is a low risk fix overall.
For now though it would be good to focus on getting a better error for Derby users using 1.6. If we find ourselves using the "Maybe they dual booted" excuse in a corruption case we can revisit whether to lobby for the 1.5 option. Sound ok?
> 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.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
Kathey Marsden updated DERBY-700:
---------------------------------
Attachment: DualBootRepro.java
DualBootRepro Program to reproduce dual boot from two classloaders in Linux.
Change DERBY_LIB_DIR to derby directory and run without derby jars in our classpath.
java -cp . DualBootRepro
> 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
> Type: Bug
> Versions: 10.1.2.1
> Reporter: Kathey Marsden
> Fix For: 10.1.3.0
> Attachments: DualBootRepro.java
>
> 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
[jira] Issue Comment Edited: (DERBY-700) Derby does not prevent
dual boot of database from different classloaders on Linux and Mac OS X
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744938#action_12744938 ]
Knut Anders Hatlen edited comment on DERBY-700 at 8/19/09 2:46 AM:
-------------------------------------------------------------------
ManagementMBeanTest started failing in the Tinderbox (trunk and 10.4) after the check-in:
http://dbtg.foundry.sun.com/derby/test/tinderbox_10.4_16/jvm1.6/testing/Limited/testSummary-805541.html
http://dbtg.foundry.sun.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-805576.html
[update: Ole has now logged this problem as DERBY-4356]
was (Author: knutanders):
ManagementMBeanTest started failing in the Tinderbox (trunk and 10.4) after the check-in:
http://dbtg.foundry.sun.com/derby/test/tinderbox_10.4_16/jvm1.6/testing/Limited/testSummary-805541.html
http://dbtg.foundry.sun.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-805576.html
> 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-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, 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.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-700:
---------------------------------
Attachment: derby-700_diff.txt
This patch is not yet ready for commit. The multithreaded test testBootingDatabaseInMultipleThread fails intermittently allowing the database to be booted twice. I am looking to see where there may be a synchronization issue.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Attachments: DERBY-700.diff, DERBY-700.stat, 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, derby700_singleproperty_v1.diff, derby700_singleproperty_v1.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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-700:
---------------------------------
The new code looks ok to me. Maybe the comment could say what we expect to throw the
OverlappingFileLockException, I assume it is:
dbLock =lockFileChannel.tryLock();
It will be great if we can count on jdk16 to fix this problem completely, finally. Too bad if we can't
get a fix out of 15 as a lot of my users still use it also.
> 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-01-aa-catchOverlappingFileLockException.diff, 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744548#action_12744548 ]
Rick Hillegas commented on DERBY-700:
-------------------------------------
Committed derby-700-01-ab-catchOverlappingFileLockException.diff at subversion revision 805448.
> 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-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, 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.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-700:
---------------------------------
Attachment: derby-700_06_07_07_diff.txt
Here is the latest patch for this issue. I think we are getting close, but I have reached a sticking point that I can't seem to get past.
If I run with classes or even with jars from within Eclipse, it all runs fine and even 100 threads pass with no problem. But for some unknown reason, when I run with jars from the commandline, it allows dual boot.
The primary change from the last patch is that I had to synchronize the entire call to privGetJBMSLockOnDB() to avoid intermittent dual boot failures in the multiThreaded test.
I also added a warning instead of failure if the user did not have permission to access the system property.
Anyway, if someone is so inclined it would be great to have another pair of eyes on this to figure out what the problem is running with jars.
I ran derbyall and suites.All. All passed with classes, but with jars ClassLoaderBootTest fails miserably.
Kathey
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504471 ]
Daniel John Debrunner commented on DERBY-700:
---------------------------------------------
-1 on this patch (now applied as 547042 & 547046):
The additional method on StorageFile is not well defined.
StorageFile.getExclusiveFileLock() indicates it gets an exclusive lock on the name represented by StorageFile.
The new method StorageFile.getLockedFile() seems to imply that if a StorageFile is locked, then there is a new
different file created to perform the lock, thus one can modify the contents of the two files independently,
using the existing StorageFile.getRandomAccessFile() and now the new StorageFile.getLockedFile().
(Otherwise why have the new method, one can already get a random access to a StorageFile??).
This seems problematic for a few reasons:
- seems inefficient, creating a new file to lock another
- seems to change the contract of the existing method getExclusiveFileLock() (no mention of requiring a separate file)
- possibly hard to implement for an arbitary IO implementation.
Maybe though I'm misunderstanding what is going on, the javadoc comment for getLockedFile() does seem to have
a couple of typos in it (e.g. "exclusing e lock"). If there's some good explanation for what is going on and the relationship
between StorageFile.getLockedFile() and StorageFile.getRandomAccessFile() can be well defined then I can frop my veto.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744592#action_12744592 ]
Rick Hillegas commented on DERBY-700:
-------------------------------------
Ported 805448 from trunk to 10.4 branch at subversion revision 805485.
> 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-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505976 ]
Kathey Marsden commented on DERBY-700:
--------------------------------------
If I try to keep the interface the same and incorporate the intrajvm lock into getExclusiveLock() I will lose granularity in the error message. With the previous patch, we had a separate intrajvm dual boot messages as well as a warning if the property was not writable. Should I add two new return possibilities from getExclusiveLock to handle these cases?
Kathey
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
Kathey Marsden updated DERBY-700:
---------------------------------
Priority: Critical (was: Major)
Marking this issue Critical as it is a corruption issue that has in the past and surely will in the future affect users and cause unrecoverable corruption in production environments. The corruption is triggered by a usage error, but unrecoverable database corruption is a high price to pay for deciding to connect with IJ while your APP Server, Eclipse or other environment has loaded Derby with a classloader.
Also marking this issue as 10.2 as a high value fix. I think there may be technical issues that make it difficult to address in the 10.2 time frame, so if someone with expertise in the area thinks it is not possible to address in that timeframe, please move it to an appropriate release, maybe 10.2.2. It is not a regression so as serious as it is I don't see it as an absolute showstopper for the release.
> 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
> Priority: Critical
> Attachments: DualBootRepro.java, DualBootRepro2.zip
>
>
> 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
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-700:
---------------------------------
Affects Version/s: (was: 10.4.1.3)
(was: 10.3.1.4)
(was: 10.2.2.0)
(was: 10.1.3.1)
(was: 10.1.2.1)
(was: 10.2.1.6)
(was: 10.1.1.0)
(was: 10.0.2.1)
(was: 10.0.2.0)
10.6.0.0
10.5.3.1
10.4.2.1
10.3.3.1
10.2.2.1
10.1.3.3
Fix Version/s: 10.6.0.0
10.5.3.1
10.4.2.1
10.3.3.1
Adjusting fix version. Fix only works with JDK 1.6 which I think is first supported with 10.3, so even though the Derby part of the fix went back to 10.1, it will only be effective there if the older jvms get fixed. I will put a request in for the IBM jvm to have the jvm fix backported to at least 1.5.
> 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.1.3.3, 10.2.2.1, 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.0.0
> 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
> Assignee: Rick Hillegas
> Priority: Critical
> Fix For: 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.0.0
>
> Attachments: derby-700-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, derby-700-02-aa-testCleanup.diff, 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.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-700:
---------------------------------
With respect to a global state in the jdbc driver when 2 class loaders are involved, how would that work with 2 different class loaders trying to run 2 different versions of derby - say 10.3 and 10.4.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Priority: Critical
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Suresh Thalamati (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504943 ]
Suresh Thalamati commented on DERBY-700:
----------------------------------------
I agree with Dan, getLockedFile() is confusing and should not be added
to the storage factory interfaces , if it can be avoided or have better
comments.
Just thought I will take a moment and explain, why in the first place
I added this method, I hope it will help in finding an alternative solution
or make the interface better.
I was testing and developing my solution on Windows. When I
first implemented without adding the getLockedFile() method, by
just getting the RandomAccessFile using StorageFile.getRandomAccessFile(),
after it is locked. I was hitting the error , java.io.IOException:
"
The process cannot access the file because another process has locked a
portion of the file. When it write UUID to the dbex.lck file.
"
After bit of debugging realized , I need access to the same
RandomAccesFile, that is used to the get the lock. So I simply
added the getLockedFile, which just return the same RandomAccessFile,
that is used to get the file lock.
public class writeLock {
public static void main(String[] args) throws Exception
{
File lf = new File("dbex.lck");
RandomAccessFile raf1 = new RandomAccessFile(lf, "rw");
FileChannel fc = raf1.getChannel();
FileLock lock = fc.tryLock();
// attempt to write to locked file using another
//
RandomAccessFile raf2 = new RandomAccessFile(lf , "rw");
// the following write is failing on windows.
raf2.writeChars("Derby is great ");
}
}
For example , in the above code. Last write will fail with the error:
Exception in thread "main" java.io.IOException: The process cannot access the
file because another process has locked a portion of the file.
I did not verify, if this is the case in the non-window environment too. This
fix is mainly for non-window environment, so If on other platforms this is
not issue then the getLockedFile() can be replaced with the
StorageFile.getRandomAccesFile(). My concern is, How to confirm all
non-window environments will not give the above error.
First I thought of putting the new intraJVM lock code in the storage
factory, where getExclusiveFileLock() is implemented, For me
It looked worse alternative too getLockedFile() method, because then
getExlusiveFileLock() method semantics gets more confusing.
Another solution I was thinking that may work without adding the
*getLockedFile() is to use the range lock. like FileLock lock =
fc.tryLock(0, 10 ,false), and write to the file after the 10th byte.
This may need a new method getExclusiveLock() , which takes range.
May be simple solution is to add a new call, getExclusiveFileLock()
method that takes RandomAcceesFile as the argument.
To start with the reason we are in this mess is the getExclusiveLock()
implementation is not matching the way java interfaces work. Ideally
store code should hold on to the RandomAccessFile used for the lock,
not the storage factory implementraion. Ideally StorageRandomAccessFile
should give handle to the StorageFileChannel, which has the tryLock()
method, that returns FileLock.
Thanks
-suresh
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-700:
--------------------------------
Attachment: derby-700-02-aa-testCleanup.diff
Thanks for those good suggestions, Knut. They are addressed by the patch I am attaching: derby-700-02-aa-testCleanup.diff.
In particular, I added a tearDown() method which resets the class loader and releases resources. It looks to me like those extra try/catch blocks were resetting the class loader on the way out--I think tearDown() is a better place for that work.
I'll run full regression tests against this fix.
> 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-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, derby-700-02-aa-testCleanup.diff, 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688145#action_12688145 ]
Kathey Marsden commented on DERBY-700:
--------------------------------------
I have been thinking about this issue and wonder:
If we put the name of the database in the name of the derby.rawStoreDaemon thread and then check for the existence of that thread before booting the database and fail if it exists, would that be a reasonable solution?
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> 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)
> 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "V.Narayanan (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
V.Narayanan reassigned DERBY-700:
---------------------------------
Assignee: (was: V.Narayanan)
Hi,
I am not working actively on this issue. Hence unassigning myself from this issue and moving on to other issues I am working on.
thanx
Narayanan
> 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
> Priority: Critical
> Fix For: 10.2.2.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
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel John Debrunner updated DERBY-700:
----------------------------------------
Derby Info: [Existing Application Impact, Release Note Needed] (was: [Release Note Needed, Existing Application Impact])
Affects Version/s: 10.4.0.0
10.3.1.1
10.3.1.0
10.3.0.0
10.0.2.0
10.0.2.1
10.1.1.0
10.1.3.1
10.2.1.6
10.2.2.0
This is an issue for every release/branch so far
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> 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.0.0, 10.3.1.0, 10.3.1.1, 10.4.0.0
> 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
> Assignee: 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504352 ]
Kathey Marsden commented on DERBY-700:
--------------------------------------
Thanks Dan for the comment.
getExclusiveLock() and getLockedFile() are only substatively relevant to DirFile4 and for that file yes, I think there is a lock file per open file. I will change the definition to say that getLockedFile() will return a RandomAcess file to the lock file obtained by getExcluciveLock() if an exclusive lock was successfully obtained with getExclusiveLock() otherwise it will return null.
Does that sound right?
I'll look at the test. Maybe I will fix it post checkin if I am not able to get it fixed up today.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-700:
--------------------------------
Issue & fix info: [High Value Fix, Patch Available] (was: [High Value Fix])
> 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-01-aa-catchOverlappingFileLockException.diff, 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504735 ]
Daniel John Debrunner commented on DERBY-700:
---------------------------------------------
Couple of minor additonal comments:
- The code would be a little simpler if getJvmId() just returned a String instead of a UUID. Then there's no need to convert
the value read back from disk to a uuid. String's compare just as well as UUIDs for this purpose.
- The reading of the on-disk identifier has this code:
+ try
+ {
+ if (exFileLock.length() != 0)
+ onDiskJvmId = uuidFactory.recreateUUID(lckFileRaf.readUTF());
+ }
+ catch (Exception e)
+ {
+ // The previous owner of the lock may have died before we
+ // finish writing its UUID down. Assume uuid file is invalid
+ // Set the id on the disk to null value.
+ onDiskJvmId = null;
+ }
- Why is the file length of zero special cased?
- I think the comment could be improved to
+ // The previous owner of the lock may have died before we
+ // finish writing its UUID down. Assume uuid file is invalid
+ // and thus the database is not in use (locked).
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-700:
---------------------------------
Attachment: derby-700_stat.txt
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Attachments: DERBY-700.diff, DERBY-700.stat, 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, derby700_singleproperty_v1.diff, derby700_singleproperty_v1.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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
Posted by "Suresh Thalamati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=comments#action_12357312 ]
Suresh Thalamati commented on DERBY-700:
----------------------------------------
My guess is , currently Derby seems to catch the IO exception and turn it into a readonly db , when file lock fails with OverlappingFileLockException. By correctly catching java.nio.channels.OverlappingFileLockException, we might be able to prevent multi boots with in the same jvm using different class loaders.
> 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
> Type: Bug
> Components: Store
> 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
> Attachments: DualBootRepro.java
>
> 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
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-700:
---------------------------------
Fix Version/s: 10.1.3.3
Updating fix version for 10.1 fix
> 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.1.3.3, 10.2.2.1, 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.0.0
> 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
> Assignee: Rick Hillegas
> Priority: Critical
> Fix For: 10.1.3.3, 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.0.0
>
> Attachments: derby-700-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, derby-700-02-aa-testCleanup.diff, 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, 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.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
Rick Hillegas updated DERBY-700:
--------------------------------
Urgency: Urgent
Bumping urgency.
> 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
> Priority: Critical
> Attachments: DualBootRepro.java, DualBootRepro2.zip
>
>
> 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
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505980 ]
Daniel John Debrunner commented on DERBY-700:
---------------------------------------------
Could the problem (needing to expand) with the synchronization be related to question I raised earlier?
>> - the synchronization for getting the intra jvm lock and releasing it are using different objects. Don't they need to use the same object?
>> If not it should be clearly commented how the synchronization is working.
In the comment above, I'm not sure which piece of code you are referring to here?
if (fileLock.exists())
{
...
----> Another thread gets in and deletes the file here
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759061#action_12759061 ]
Knut Anders Hatlen commented on DERBY-700:
------------------------------------------
I think 10.1 is supposed to work with Java 6 as well. Support for JDBC 4.0 wasn't added until 10.2, but as long as your application only calls JDBC 3.0 functionality, you should be able to run it with older Derby versions under Java 6. I frequently run older versions with Java 6, for instance when I search for the version that introduced a certain bug.
> 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.1.3.3, 10.2.2.1, 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.0.0
> 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
> Assignee: Rick Hillegas
> Priority: Critical
> Fix For: 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.0.0
>
> Attachments: derby-700-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, derby-700-02-aa-testCleanup.diff, 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Suresh Thalamati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=comments#action_12363295 ]
Suresh Thalamati commented on DERBY-700:
----------------------------------------
Hi Kathy ,
I am attempting to fix this bug, just realized I may not be able to add the repro in jira into the functional tests., repro is expecting derby classes should not be in there in the classpath, I was wondering by chance did u write a custom class loader test for Derby ? I could not find one in the functional tests.
Thanks
-suresh
> 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
> Type: Bug
> Components: Store
> 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
> Assignee: Suresh Thalamati
> Attachments: DualBootRepro.java
>
> 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
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745098#action_12745098 ]
Rick Hillegas commented on DERBY-700:
-------------------------------------
Committted derby-700-02-aa-testCleanup.diff at subversion revision 805858. Tests ran cleanly for except for the spillover consequences for ManagementMBeanTest--the regression there is unchanged.
> 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-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, derby-700-02-aa-testCleanup.diff, 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.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-700:
---------------------------------
Attachment: releaseNote.html
Attaching a new release note. The old one referred to the original proposed fix which was not adopted. Please review.
> 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.1.3.3, 10.2.2.1, 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.0.0
> 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
> Assignee: Rick Hillegas
> Priority: Critical
> Fix For: 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.0.0
>
> Attachments: derby-700-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, derby-700-02-aa-testCleanup.diff, 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, 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Suresh Thalamati (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483798 ]
Suresh Thalamati commented on DERBY-700:
----------------------------------------
There does not seem to be any way to get process id info that can be used to fix this problem. Existing JVM enhancement requests filed to get process id info:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4250622
http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=7c75c6fc92c662c739fb11f620a4:YfiG?bug_id=4244896
It was interesting to reade these reports, other developers are finding it hard to generate unique id across jvms!
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Priority: Critical
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-700:
--------------------------------
Attachment: DualBootRepro.java
It appears to me that a workaround for this bug is to upgrade to Java 6. I am attaching a slightly revised version of the repro, DualBootRepro.java (this revision contains all of the helper classes needed to create the failure scenario). I see failures on the following platforms:
Apple Java 5 on Mac OS X
Sun Java 5 on Ubuntu Linux
IBM Java 5 on Ubuntu Linux
Happily, however, the second boot fails and raises java.nio.channels.OverlappingFileLockException on the following platforms:
Apple Java 6 beta on Mac OS X
Sun Java 6 on Ubuntu Linux
IBM Java 5 on Ubuntu Linux
Admittedly, that's a graceless failure. However, I think it should prevent the database from being corrupted and it's worth recommending an upgrade to Java 6 for users who encounter this bug.
> 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.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
Rick Hillegas updated DERBY-700:
--------------------------------
Fix Version/s: 10.2.3.0
(was: 10.2.2.0)
Move to 10.2.3.0.
> 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
> Priority: Critical
> Fix For: 10.2.3.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
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504446 ]
Daniel John Debrunner commented on DERBY-700:
---------------------------------------------
> I think there is a lock file per open file. I will change the definition to say that getLockedFile() will return a RandomAcess file to the lock file obtained by getExcluciveLock() if an exclusive lock was successfully obtained with getExclusiveLock() otherwise it will return null.
Sorry, still somewhat lost. Why is a call to get a random access file on StorageFile needed since it already has such a method?
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren updated DERBY-700:
-------------------------------------
Attachment: releaseNote.html
Looks good, but there were 2 typos...uploading a corrected version.
> 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.1.3.3, 10.2.2.1, 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.0.0
> 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
> Assignee: Rick Hillegas
> Priority: Critical
> Fix For: 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.0.0
>
> Attachments: derby-700-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, derby-700-02-aa-testCleanup.diff, 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, 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.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-700:
---------------------------------
Attachment: derby-700_06_07_07_stat.txt
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
Rick Hillegas updated DERBY-700:
--------------------------------
Fix Version/s: 10.2.0.0
> 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
> Priority: Critical
> Fix For: 10.2.0.0
>
> Attachments: DualBootRepro.java, DualBootRepro2.zip
>
>
> 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
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-700:
--------------------------------
Attachment: derby-700-01-aa-catchOverlappingFileLockException.diff
Attaching derby-700-01-aa-catchOverlappingFileLockException.diff. This patch catches the OverlappingFileLockException, releases the channel, and sets the status to indicate that another Derby instance has locked the database. I have not run any tests yet other than verifying that the repro runs correctly on Java 6, but I'm posting this patch to see if the Store experts think this looks right. Once we agree that the code looks good, we can write some additional regression tests for this problem.
Touches the following file:
M java/engine/org/apache/derby/impl/io/DirFile4.java
> 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-01-aa-catchOverlappingFileLockException.diff, 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740623#action_12740623 ]
Kathey Marsden commented on DERBY-700:
--------------------------------------
This is indeed excellent news.
I tried on SuSE with:
java version "1.6.0"
Java(TM) SE Runtime Environment (build pxi3260sr4-20090216_01(SR4))
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20090215_29883 (JIT enabled, AOT enabled)
J9VM - 20090215_029883_lHdSMr
JIT - r9_20090213_2028
GC - 20090213_AA)
JCL - 20090214_01
and indeed got the OverlappingFileLockException and tried with the property you mentioned and saw dual boot. When I get back from vacation, I will review my case records and revisit the dual boot case we saw with 1.6 and see if it is something else.
I think the important thing is to have a solution moving forward, so think we should just catch this exception and throw a dual boot message. While an older jvm solution would be great, I think most of the legacy applications that have dual boot have learned their lesson the hard way with corruption and no longer do it. It is in application development that we need to catch this and throw a clear message. That development usually happens with newer JVM's.
Do you have a bug number/link for the JVM fix?
> 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740552#action_12740552 ]
Rick Hillegas commented on DERBY-700:
-------------------------------------
Hi Kathey. I'm now aware of a spec clarification but I will ask around. I agree that we still need a solution for people whose VMs don't raise OverlappingFileLockException in this situation. Just thought that we might be able to spare some users a data corruption by recommending that they experiment with Java 6.
> 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740673#action_12740673 ]
Rick Hillegas commented on DERBY-700:
-------------------------------------
I think it's a good idea to clean up how we handle java.nio.channels.OverlappingFileLockException . I agree that we can revisit this bug if that solution proves to be inadequate.
> 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744657#action_12744657 ]
Rick Hillegas commented on DERBY-700:
-------------------------------------
At this point I have ported the patch to all branches from 10.2 forward. If someone would like to port the patch to 10.1, please do--my 10.1 build environment no longer works and the effort required to repair it does not seem justified.
I am inclined to resolve this issue if there are no objections.
> 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-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744632#action_12744632 ]
Rick Hillegas commented on DERBY-700:
-------------------------------------
Ported 805448 from trunk to 10.2 branch at subversion revision 805523.
> 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-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743447#action_12743447 ]
Kathey Marsden commented on DERBY-700:
--------------------------------------
There was a test in the earlier patches that might be of use.
> 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-01-aa-catchOverlappingFileLockException.diff, 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505310 ]
Kathey Marsden commented on DERBY-700:
--------------------------------------
Dan, based on what Suresh said, does the solution to add a new call, getExclusiveFileLock()
method that takes RandomAcceesFile as the argument seem like a reasonable solution to get rid of getLockedFile or should we just document getLockedFile better, or something else ...?
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DERBY-700) Derby does not prevent
dual boot of database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740552#action_12740552 ]
Rick Hillegas edited comment on DERBY-700 at 8/7/09 7:14 AM:
-------------------------------------------------------------
Hi Kathey. I'm not aware of a spec clarification but I will ask around. I agree that we still need a solution for people whose VMs don't raise OverlappingFileLockException in this situation. Just thought that we might be able to spare some users a data corruption by recommending that they experiment with Java 6.
was (Author: rhillegas):
Hi Kathey. I'm now aware of a spec clarification but I will ask around. I agree that we still need a solution for people whose VMs don't raise OverlappingFileLockException in this situation. Just thought that we might be able to spare some users a data corruption by recommending that they experiment with Java 6.
> 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.
[jira] Assigned: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden reassigned DERBY-700:
------------------------------------
Assignee: (was: Kathey Marsden)
Unassigning myself from this issue for now. I am not actively working on it and am not sure how to resolve the synchronization issue I was seeing when running the test with many threads. Hopefully someone else will be able to find a solution which does not expand the synchronization so much.
Kathey
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> 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.0.0
> 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
> 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740540#action_12740540 ]
Kathey Marsden commented on DERBY-700:
--------------------------------------
Thank you Rick for looking at this issue. I think it sorely needs a new pair of eyes. I know I have seen dual boot on SuSE Linux with IBM 1.6, but have not tried the recent fix packs. I have seen the OverlappingFileLockException on IBM 1.6 with z/OS, but thought it was a JVM bug working in our favor. Has there been recent spec clarification that exclusive java.nio.FileLocks should prevent cross classloader access? If we determine that the OverlappingFileLockException is the correct JVM behavior, then I think we can catch that exception and throw a dual boot message and then file JVM bugs where we don't see the OverlappingFileLockException.
> 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.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-700:
---------------------------------
keep in mind that if we make setting/reading the property optional it presents a very mixed set of possiblities. We need to at least document and maybe refer to them in the error message. Each derby.jar in each different class loader may have a different property set so one set may be able to read but not write, another can't read or write, and another can read and write. Some app may get different locking behaviors if they can read by not write based on whether they are the first one in or not ( they sometimes may get error message and sometimes not based on what someone else has done).
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, 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, 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
Rick Hillegas updated DERBY-700:
--------------------------------
Fix Version/s: 10.2.2.0
(was: 10.3.0.0)
Thanks for creating the new 10.2.2.0 option, Andrew! I've reassigned this issue to that release.
> 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.2.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
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-700:
--------------------------------
Attachment: releaseNote.html
Scrubbing release note so that it can be digested by the SAX parser in the release note generator. Naked <br> tags replaced with <br/>.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
Re: (10.2 maintenance release version for Jira?) Re: [jira] Updated:
(DERBY-700) Derby does not prevent dual boot of database from different classloaders
on Linux
Posted by Satheesh Bandaram <ba...@gmail.com>.
Hi Rick,
Currently both Andrew and myself have JIRA-admin access, though Andrew
has been doing all the work lately.
I have been thinking of giving up my JIRA-admin access... May be the
right time now to switch it over to you, since you are the release
manager for 10.2.
Satheesh
Rick Hillegas wrote:
> Yes, please! If I knew the JIRA magic to do this, I would mumble it.
> Could someone teach me the magic, and if necessary, give me karma to
> mumble?
>
> Thanks,
> -Rick
>
> Kathey Marsden wrote:
>
>> Rick Hillegas (JIRA) wrote:
>>
>>> It appears that fixing this bug will require us to agree on some
>>> mechanism for caching VM-global Derby state. This seems to be an
>>> architectural decision which requires careful thought and
>>> experiment. I think we should defer this to a future release. I am
>>> moving this to 10.3 because thatt's the next release available in
>>> the dropdown. I agree with Kathey that this is a good candidate for
>>> a bug fix release in the 10.2 lineage.
>>>
>>>
>>>
>> Sounds like a reasonable move since there is no immediate solution
>> apparent. I was wondering though, could we could add a new version
>> that we can use as some of the 10.2 candidates start getting moved
>> out? I want to say 10.2.2.0 but am not sure that is right.
>>
>> Kathey
>>
>>
>>
>
>
Re: Re: (10.2 maintenance release version for Jira?) Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
Posted by Andrew McIntyre <mc...@gmail.com>.
On 8/3/06, Satheesh Bandaram <ba...@gmail.com> wrote:
>
> Can you please take me off from JIRA-admin group? JIRA says I can't
> remove my own membership to this group!
done.
Re: (10.2 maintenance release version for Jira?) Re: [jira] Updated:
(DERBY-700) Derby does not prevent dual boot of database from different classloaders
on Linux
Posted by Satheesh Bandaram <ba...@gmail.com>.
Andrew McIntyre wrote:
> On 8/3/06, Rick Hillegas <Ri...@sun.com> wrote:
>
>> Yes, please! If I knew the JIRA magic to do this, I would mumble it.
>> Could someone teach me the magic, and if necessary, give me karma to
>> mumble?
>
>
> granted. the admin pages are your friends.
Can you please take me off from JIRA-admin group? JIRA says I can't
remove my own membership to this group!
Or Rick, you want to try doing this and use your new karma? :)
Satheesh
Re: (10.2 maintenance release version for Jira?) Re: [jira] Updated:
(DERBY-700) Derby does not prevent dual boot of database from different
classloaders on Linux
Posted by Rick Hillegas <Ri...@Sun.COM>.
Andrew McIntyre wrote:
> On 8/3/06, Rick Hillegas <Ri...@sun.com> wrote:
>
>> Yes, please! If I knew the JIRA magic to do this, I would mumble it.
>> Could someone teach me the magic, and if necessary, give me karma to
>> mumble?
>
>
> granted. the admin pages are your friends.
Thanks, Andrew. Where can I find my new friends, the admin pages? I
tried clicking on the Administration tab on a JIRA report, but that
didn't take me to a page with useful links.
Regards,
-Rick
>
>> Kathey Marsden wrote:
>>
>> > Sounds like a reasonable move since there is no immediate solution
>> > apparent. I was wondering though, could we could add a new version
>> > that we can use as some of the 10.2 candidates start getting moved
>> > out? I want to say 10.2.2.0 but am not sure that is right.
>
>
> Yep, that's right. I've added this version to JIRA. We need this also
> to track the inevitable removal of our "early-access" language around
> the JDBC 4 bits. Which reminds me...
Re: (10.2 maintenance release version for Jira?) Re: [jira] Updated:
(DERBY-700) Derby does not prevent dual boot of database from different
classloaders on Linux
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Hi,
Andrew McIntyre <mc...@gmail.com> writes:
> Yep, that's right. I've added this version to JIRA. We need this also
> to track the inevitable removal of our "early-access" language around
> the JDBC 4 bits. Which reminds me...
Could you please also add an entry for version 11? Cf my need
mentioned here:
http://www.nabble.com/forum/ViewPost.jtp?post=5604369&framed=y
Dag
Re: Re: (10.2 maintenance release version for Jira?) Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
Posted by Andrew McIntyre <mc...@gmail.com>.
On 8/3/06, Rick Hillegas <Ri...@sun.com> wrote:
> Yes, please! If I knew the JIRA magic to do this, I would mumble it.
> Could someone teach me the magic, and if necessary, give me karma to mumble?
granted. the admin pages are your friends.
> Kathey Marsden wrote:
>
> > Sounds like a reasonable move since there is no immediate solution
> > apparent. I was wondering though, could we could add a new version
> > that we can use as some of the 10.2 candidates start getting moved
> > out? I want to say 10.2.2.0 but am not sure that is right.
Yep, that's right. I've added this version to JIRA. We need this also
to track the inevitable removal of our "early-access" language around
the JDBC 4 bits. Which reminds me...
Re: (10.2 maintenance release version for Jira?) Re: [jira] Updated:
(DERBY-700) Derby does not prevent dual boot of database from different
classloaders on Linux
Posted by Rick Hillegas <Ri...@Sun.COM>.
Yes, please! If I knew the JIRA magic to do this, I would mumble it.
Could someone teach me the magic, and if necessary, give me karma to mumble?
Thanks,
-Rick
Kathey Marsden wrote:
> Rick Hillegas (JIRA) wrote:
>
>> It appears that fixing this bug will require us to agree on some
>> mechanism for caching VM-global Derby state. This seems to be an
>> architectural decision which requires careful thought and experiment.
>> I think we should defer this to a future release. I am moving this to
>> 10.3 because thatt's the next release available in the dropdown. I
>> agree with Kathey that this is a good candidate for a bug fix release
>> in the 10.2 lineage.
>>
>>
>>
> Sounds like a reasonable move since there is no immediate solution
> apparent. I was wondering though, could we could add a new version
> that we can use as some of the 10.2 candidates start getting moved
> out? I want to say 10.2.2.0 but am not sure that is right.
>
> Kathey
>
>
>
(10.2 maintenance release version for Jira?) Re: [jira] Updated:
(DERBY-700) Derby does not prevent dual boot of database from different classloaders
on Linux
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas (JIRA) wrote:
>It appears that fixing this bug will require us to agree on some mechanism for caching VM-global Derby state. This seems to be an architectural decision which requires careful thought and experiment. I think we should defer this to a future release. I am moving this to 10.3 because thatt's the next release available in the dropdown. I agree with Kathey that this is a good candidate for a bug fix release in the 10.2 lineage.
>
>
>
Sounds like a reasonable move since there is no immediate solution
apparent. I was wondering though, could we could add a new version
that we can use as some of the 10.2 candidates start getting moved out?
I want to say 10.2.2.0 but am not sure that is right.
Kathey
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Daniel John Debrunner <dj...@apache.org>.
Mike Matrigali wrote:
> great, sounds like the sync part is a non-issue. I was stuck trying
> to come up with something specific to the db shared across both
> classloaders that we could sync on. Using this will single thread
> opens of different dbs, but I think that is ok.
Then I think you would want something like:
String syncDB = file.getCanonicalPath().intern();
synchronized (syncDB)
{
}
Dan.
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Mike Matrigali <mi...@sbcglobal.net>.
great, sounds like the sync part is a non-issue. I was stuck trying
to come up with something specific to the db shared across both
classloaders that we could sync on. Using this will single thread
opens of different dbs, but I think that is ok.
Daniel John Debrunner wrote:
> Mike Matrigali wrote:
>
>
>
>>If anyone has ideas on this one, please post them. I have been stumped
>>by this one so far. As I posted earlier I think one approach simply
>>needs a way to uniquely identify the current JVM, and also some way
>>to coordinate a sync block across 2 class loaders.
>
>
> A Java synchronized block across class loaders is easy, either
> of these will work. But I'm not sure if that's what you really meant,
> but I'd thought I'd throw it out there.
>
> synchronized ("derby")
> {
> }
>
> synchronized ("")
> {
> }
>
> Dan.
>
>
>
>
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Daniel John Debrunner <dj...@apache.org>.
Mike Matrigali wrote:
> If anyone has ideas on this one, please post them. I have been stumped
> by this one so far. As I posted earlier I think one approach simply
> needs a way to uniquely identify the current JVM, and also some way
> to coordinate a sync block across 2 class loaders.
A Java synchronized block across class loaders is easy, either
of these will work. But I'm not sure if that's what you really meant,
but I'd thought I'd throw it out there.
synchronized ("derby")
{
}
synchronized ("")
{
}
Dan.
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Rick Hillegas (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
>
> Rick Hillegas updated DERBY-700:
> --------------------------------
>
> Fix Version/s: 10.3.0.0
> (was: 10.2.0.0)
>
> It appears that fixing this bug will require us to agree on some mechanism for caching VM-global Derby state. This seems to be an architectural decision which requires careful thought and experiment. I think we should defer this to a future release. I am moving this to 10.3 because thatt's the next release available in the dropdown. I agree with Kathey that this is a good candidate for a bug fix release in the 10.2 lineage.
>
If anyone has ideas on this one, please post them. I have been stumped
by this one so far. As I posted earlier I think one approach simply
needs a way to uniquely identify the current JVM, and also some way
to coordinate a sync block across 2 class loaders. So far I have
been convinced by dan and david that using System properties is the
wrong approach.
As kathy has said the consequences of this is that
user may corrupt the db so it is bad. We should document either in
release notes or the main documentation that Derby does not currently
support accessing the same db, in the same JVM, from 2 separate class
loaders. System properties in general are a problems for this
configuration, and I believe we do no testing of the configuration
either. Any opinions on where this info should show up.
As this is an unsupported configuration, I believe that it should not
hold up the 10.2 release, but I also agree that whenever we get an
agreed upon fix it should go into the next release of all current
releases.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
Rick Hillegas updated DERBY-700:
--------------------------------
Fix Version/s: 10.3.0.0
(was: 10.2.0.0)
It appears that fixing this bug will require us to agree on some mechanism for caching VM-global Derby state. This seems to be an architectural decision which requires careful thought and experiment. I think we should defer this to a future release. I am moving this to 10.3 because thatt's the next release available in the dropdown. I agree with Kathey that this is a good candidate for a bug fix release in the 10.2 lineage.
> 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.3.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
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Suresh Thalamati (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Suresh Thalamati updated DERBY-700:
-----------------------------------
Attachment: derby700_singleproperty_v1.stat
derby700_singleproperty_v1.diff
Attached is a patch with partial implementation of the intra-jvm db
lock mechanism to prevent users from running multiple instances of the same
database using different class loaders in the same jvm. Existing
solution already prevents users from running multiple instances across jvms.
Although I have not assigned this issue to myself, have been working on this
issue on/off for some time. But I don't have free cycles to work on this bug for
the upcoming release. I am posting the patch with whatever work I have done
sofar. If some one can enhance the attached patch and fix this issue,
that will be great.
Intra-jvm db lock is provided by using global derby specific jvm instance id.
On a first boot of any derby database in a jvm, an UUID is generated and
stored in a system property ("derby.storage.jvmInstanceID"). This id is written
to the dbex.lck file when the database is booted. If the ID in the dbex.lck file
and the current jvm id stored in the system property
"derby.storage.jvmInstanceID" are same then the database is already booted, and
an exception will be thrown and database will not be booted. On a database
shutdown , an Invalid JVM id is written to the dbex.lck file, so that if the
database booted again ID's will not be equal, which means database is not
already booted, the database will be booted successfully. I am using the
existing UUID factory in the derby to generate the derby jvm id.
Synchronization is done by using the interned strings. Synchronization
across the JVM is done on "derby.storage.jvmInstanceID" string. And
Synchronization for a database is done on the database directory. This
may need to be changed to a database name, because it may not be possible
to get the canonical path always and it is necessary to synchronize on
a string, that is unique to a database in a jvm.
In my earlier proposed solution I mentioned about releasing the db
locks using finalizer. After doing some testing , I realized there is
no need to address unlocking the database on garbage collection,
using the finalizer. My understanding is unless users shutdown
the database rawStoreDaemon and antiGC thread will hold on to the
resources and the classes will not be unloaded. So the only way users
can boot an already booted database but not in use using another class
loader instance in the same jvm is by doing a shutdown from the class
loader that booted the database. If some thinks this is not
true, please correct me.
To do :
1) cleanup error handling on IOExceptions and add new message for the
intra-jvm db lock.
2) Currently dataDirectory path string is is used for synchronization to
prevent multiple boots of a database. This may need to be changed to
the db name.
3) Make the classLoaderBootTest.java run under security manager.
4) Add test cases for booting different databases parallelly on different
threads with different class loaders. May not be really required , because
even booting a single database through different threads shoud test
the same thing. But it may be better to add a test case, just to be safe!
5) Run the test with large number of threads.
6) Anything else I have forgotten !
Thanks
-suresh
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Priority: Critical
> 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, derby700_singleproperty_v1.diff, derby700_singleproperty_v1.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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505957 ]
Kathey Marsden commented on DERBY-700:
--------------------------------------
I am working to move the intraJVM lock into StorageFile, getExclusiveLock()/ releaseExclusiveLock, but I wanted to comment on why I expanded the synchronization to include all of privGetJBMSLockOnDB as I think that will still be required.
I found running the test with multiple threads that I would get occasional dual boot without any error message or warning with the original patch. I expanded the synchronization and found that it corrected the problem. I think there seems to be a window where two threads can get in and create or delete the lock file at the same time, e.g.
if (fileLock.exists())
{
...
----> Another thread gets in and deletes the file here
I am not totally sure that this is the hole and since this logic would remain in BaseDataFileFactory we would still need to synchronize on the interned databaseName there. I am sure however that it works with the expanded synchronization but does not without it.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Suresh Thalamati (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484586 ]
Suresh Thalamati commented on DERBY-700:
----------------------------------------
Thanks for confirming , Dan. I was referring to the commnet you noted. Looks like there is NO way to maintain an in-memory state that is global to JVM across class loader , other than using a system property.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Priority: Critical
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=comments#action_12424951 ]
Daniel John Debrunner commented on DERBY-700:
---------------------------------------------
LUCENE-305 and LUCENE-635 may be worth looking at, lucene is re-factoring their locking (similar requirements to Derby) and maybe they have a solution for the intra-jvm lock. Otherwise has anyone done a google search on the issue?
> 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, DualBootRepro.java, DualBootRepro2.zip
>
>
> 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
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484565 ]
Daniel John Debrunner commented on DERBY-700:
---------------------------------------------
if you alluding to this comment:
rick> One Derby object that's global across the VM is the Derby driver registered with the DriverManager.
then I think that is false. Derby will have multiple drivers registered, one per classloader that booted derby.
(see comments for DERBY-1228 or java.sql.DriverManager documentation)
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Priority: Critical
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-700:
--------------------------------
Description:
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.
was:
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.
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.
was:
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)
Summary: Derby does not prevent dual boot of database from different classloaders on Linux and Mac OS X (was: Derby does not prevent dual boot of database from different classloaders on Linux)
Amended the title, description, and environment fields. This bug also appears on the Apple Java 5 VM on Mac OS X 10.5.7. It appears that this bug is not limited to Linux.
> 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, 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.
[jira] Assigned: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "V.Narayanan (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
V.Narayanan reassigned DERBY-700:
---------------------------------
Assignee: V.Narayanan
> 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: DualBootRepro.java, DualBootRepro2.zip
>
>
> 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
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-700:
---------------------------------
Derby Info: [Existing Application Impact, Release Note Needed] (was: [Release Note Needed, Existing Application Impact])
Dan I would like to understand your concerns with respect to the locking interfaces on StorageFile. We are only going to call locking on the lock files, not on other RandomAccessFiles. The current code is using the exising RandomAccessFile support
to do this - do you think we should be creating a different type of file rather than putting the interfaces on StorageFile?
I agree the comments could be improved, and I guess since we are so close to a release it is better to get it right before checkin. I was ok before with checking it in as it was and then fixing in subsequent checkin (I was planning on helping with this once code got in, instead of a patch).
At this point it looks like this won't make it into first release candidate, but I plan on helping to get this to a good state for a subsequent release candidate or at least get it into the branch for anyone who wants it if we don't have another release candidate. I would not hold up release candidate for this. I think it is reasonable to get the documentation for the requested permission into the release even if we can't get the code in this week, is that a problem?
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745229#action_12745229 ]
Myrna van Lunteren commented on DERBY-700:
------------------------------------------
I backported the change to DirFile4.java of 805448 to 10.1 with revision 805978.
> 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-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, derby-700-02-aa-testCleanup.diff, 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506228 ]
Kathey Marsden commented on DERBY-700:
--------------------------------------
Dan asked:
>Could the problem (needing to expand) with the synchronization be related to question I raised earlier?
>> - the synchronization for getting the intra jvm lock and releasing it are using different objects. Don't they need to use the same object?
No even with that corrected the test still fails with only putting synchronization on getIntraJVMDBLock()
In the comment above, I'm not sure which piece of code you are referring to here?
This is from privGetJBMSLockOnDB()
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-700:
---------------------------------
Attachment: derby-700_with_NPE_fix_stat.txt
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Attachments: DERBY-700.diff, DERBY-700.stat, 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, 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504721 ]
Daniel John Debrunner commented on DERBY-700:
---------------------------------------------
Note I'm reviewing the patch called; derby-700_06_07_07_diff.txt
Comments on 6/12 seem to indicate a new patch for review but nothing seems to have been attached that day, I think those comments are about the previous version.
Some comments on the patch:
- In getIntraJvmDbLock() there is this comment:
+ // synchronizing across the same database, by using interned
+ // version of the database name
but I can't see any synchronization. It seems the synchronization has moved to wrap the entire call to privGetJBMSLockOnDB().
Since this synchronization is key it would be good to get the comments clear so that future readers can understand how this works.
Also I think putting the synchronization in the privGetJBMSLockOnDB() method would be much clearer than hiding it in the run() method.
I see the comment above indicating the synchronization was expanded to be the full privGetJBMSLockOnDB() method, but there is
no reason given. Can you share your thoughts on why this is required?
- the synchronization for getting the intra jvm lock and releasing it are using different objects. Don't they need to use the same object?
If not it should be clearly commented how the synchronization is working.
- In getIntraJvmDbLock() and releaseIntraJvmDbLock() the StorageAccessFile lckFileRaf is never closed, I think it needs to be or have comments indicating why it is not closed. Maybe it's related to the issue of the new method added to StorageFile??
- In releaseIntraJvmDbLock() I was a little unclear by the invalid uuid concept. Is it an invalid uuid such that recreateUUID will throw an exception in getIntraJvmDbLock() or is it a valid representation of a uuid that can never be created by Derby?
- Using dataDirectory.intern() to synchronize across class loaders in releaseIntraJvmDbLock() could probably use more comments, basically describing what guarantees that all derby systems have the same path for the data directory for a given database?
Thanks for working on this, it will help stop users corrupting their own databases.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750601#action_12750601 ]
Mamta A. Satoor commented on DERBY-700:
---------------------------------------
Rick, I was wondering if you knew the correlation between DERBY-700 and DERBY-4361. testDefault fixture in ErrorStreamTest has been failing consistently after the checkin went in for DERBY-700. If the test orders are changed and ErrorStreamTest is run after the test ClassLoaderBootTest which was added for DERBY-700, testDefault fixture does not fail anymore. I will look further into what the relationship between the 2 jira entries might be but I thought I would check if it rings a bell for you. Thanks
> 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
> Assignee: Rick Hillegas
> Priority: Critical
> Attachments: derby-700-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, derby-700-02-aa-testCleanup.diff, 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502848 ]
Kathey Marsden commented on DERBY-700:
--------------------------------------
Run without security manager the test passes with jars. So I will try to figure out what permission is missing/needed with jars.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509163 ]
Daniel John Debrunner commented on DERBY-700:
---------------------------------------------
With the changes made for DERBY-2737 it might be wise to get the template server policy file to include the permission on the property derby.storage.jvmInstanceId even if this fix doesn't make it into the first 10.3 release. At least then any user's policy file might have a better chance of having the permission.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "V.Narayanan (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
V.Narayanan updated DERBY-700:
------------------------------
Attachment: DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff
DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat
DualBootRepro_mutltithreaded.tar.bz2
Hi,
THESE ATTACHMENTS ARE JUST AN ATTEMPT IN THE SIMULATION OF THE COMMENTS ABOVE. THEY ARE NOT FOR A COMMIT. PLS FOLLOW BELOW COMMENTS FOR DETAILS.
Thanx for going through the patch and giving comments
>Using system properties will require that every user running with the security
manager grant a new permission in their policy file to allow setting these system
properties.
I Agree, My apologies for not having gone through the earlier thread on System
Properties
> One issue with system properties is that how do atomically set and get the
property, I think that is needed to perform locking? In your current patch, there is a
window between where you get and set the property where another thread in a
anoter class loader could come in and "lock" the database, resulting in two active
derby instances connecting to the same database.
Again a very valid point. I wanted to try to simulate this. So converted the whole
repro into a crude multi -threaded application. But found found it difficult to
simulate it on my machine since one of the threads always managed to set this
property before the other. So modified my fix by creating a sort of sync point after
the getProperties. Just to show that two seperate threads could actually reach
there.
This could actually occur without this modification
1) When one of the threads gets preempted after doing a getProperties and then
the other does a getProperties. And then they proceed to completion.
Also this might just be one of the cases when this could have occurred.
> I also don't understand why on getting the system property you are catching
NullPointerException and IllegalArgumentException, how would these be thrown
by System.getProperty()?
NullPointerException - System.getProperty(null);
IllegalArgumentException - System.getProperty("");
I found it interesting to simulate the condition where the above fix might fail.
Thought I could share the same with the community. So attaching the relevant files
I used for generating this condition.
thanx once again for the patient comments
Narayanan
> 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
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Issue Comment Edited: (DERBY-700) Derby does not prevent
dual boot of database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Suresh Thalamati (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498050 ]
Suresh Thalamati commented on DERBY-700:
----------------------------------------
[ Show » ] Kathey Marsden [22/May/07 03:22 PM] Thanks Suresh for the patch! I was wondering, why do we need
setContextClassLoader privileges for derby.jar with the change?
I must have added that permission while debugging to run the test under security manager.
Only security permission that is required for derby.jar is read/write of derby.storage.jvmInstanceID
property.
Thanks for for volunteering to fix the bug, Kathey.
.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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: Kathey Marsden
> Priority: Critical
> 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, derby700_singleproperty_v1.diff, derby700_singleproperty_v1.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.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Suresh Thalamati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
Suresh Thalamati reassigned DERBY-700:
--------------------------------------
Assign To: Suresh Thalamati
> 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
> Type: Bug
> Components: Store
> 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
> Assignee: Suresh Thalamati
> Attachments: DualBootRepro.java
>
> 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
[jira] Assigned: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden reassigned DERBY-700:
------------------------------------
Assignee: Kathey Marsden
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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: Kathey Marsden
> Priority: Critical
> 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, derby700_singleproperty_v1.diff, derby700_singleproperty_v1.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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505330 ]
Daniel John Debrunner commented on DERBY-700:
---------------------------------------------
Thanks Suresh, that was very useful. The piece of missing information for me was that on windows one can only have one open descriptor against a locked file (from Suresh's description).
So really this method was added because the existing (pre-patch) *implementation* of StorageFile does *not* honour the contract of StorageFile. This is because with this implementation (on some platforms) if StorageFile.getExclusiveFileLock() is called then StorageFile.getRandomAccessFile() does *not* return an object that can be used to modify the file.
In fact looking at the DirFile implementation it seems the file locking implementation is not what a reader of the IO api (the javadoc for StorageFile) might expect. I read the StorageFile javadoc and expect that getExclusiveFileLock() puts a lock on the file, I can then use it as a regular file and then release the lock. Then another thread/jvm could perform the same action and we would have normal file locking sematics. That's why the change confused me, because I was expecting certain behaviour based upon the contract of StorageFile.
But the DirFile/DirFile4 implementations are not that and are not even identical to each other (in terms of visible behaviour).
- DirFile Calling getExclusiveFileLock() deletes the file if it exists and then creates it
- DirFile4 Creates the file and writes four bytes into it.
- Once a storage file is locked, it can not be used as a regular file
- releasing the lock deletes the file(!!)
I can see why all of this is done, it's for a specific purpose for locking Derby databases, but I don't think anyone would expect either
of those implementations from reading the api.
Thus I think first the StorageFile javadoc should be changed to describe the behaviour implemented (since it's all that is required by Derby today).
I think the generalities of it are:
- Any StorageFile that has getExclusiveFileLock() called on it is not intended to be read from or written to. It's sole purpose is to provide
a locked entity to avoid multiple instances of Derby accessing the same database.
- getExclusiveFileLock() may delete or overwrite any existing file
- releaseExclusiveFileLock() may delete the file
Then I wonder if this new locking mechanism for intra-jvm locks should be contained within the DirFile4 StorageFile implementation.
The code is completly reliant on that implementation, so why not enclose it? Then there would be no need to change the StorageFactory interface (after from the comments clarifying behaviour).
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by Narayanan <V....@Sun.COM>.
Hi,
Thanx a ton for the issues you have highlighted. I am sorry to have
missed on the earlier chain of emails regarding proposal of single
system property. I was just proposing the system property as a possible
solution and I see the arguments against it as valid. My attempt at
creating a rather crude simulation of the problem that can occur because
of synchronization is attached to derby-700.
thanx once again,
Narayanan
Mike Matrigali wrote:
> I haven't looked at this yet, just wanted to say that when I proposed
> a single system property (vs. one system prop per database), there was
> opposition in the community.
>
> Some things to think about:
> o can the same database ever have "2" names - ie. if the location is
> /x/y/wombat and one person accesses as system=/x and db=y/wombat
> and another system= /x/y and db=wombat.
>
> o what about when a derby instance fails, like a null pointer or some
> othe bug. Will the system prop be left around?
>
> o how do you handle synchronization of 2 connects at basically the same
> time?
>
> V.Narayanan (JIRA) wrote:
>> [ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
>>
>> V.Narayanan updated DERBY-700:
>> ------------------------------
>>
>> Attachment: DERBY-700.diff
>> DERBY-700.stat
>>
>> Hi,
>>
>> We could solve this problem by setting a System property before
>> booting a database and checking for the property during subsequent
>> boots. When the database is shutdown we set the property to false.
>> For example when we boot a database named mydb then we set the
>> property derby.dblock.mydb = true. Now during subsequent boots we
>> could check for this system variable and if it is set to true throw
>> an exception. During the shutdown of the database we set this
>> variable to false. I tried an attempt along this line in the attached
>> patch.
>> I HAVE NOT run the patch with security manager enabled. The sample
>> repro attached with this issue passes with this fix.
>> Pls note that the patch is not for a commit but is just to represent
>> what I have in mind as a solution, in the form of code.
>> thanx
>> Narayanan
>>
>>
>>> 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,
>>> DualBootRepro.java, DualBootRepro2.zip
>>>
>>>
>>> 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.
>>
>>
>
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I haven't looked at this yet, just wanted to say that when I proposed a
single system property (vs. one system prop per database), there was
opposition in the community.
Some things to think about:
o can the same database ever have "2" names - ie. if the location is
/x/y/wombat and one person accesses as system=/x and db=y/wombat
and another system= /x/y and db=wombat.
o what about when a derby instance fails, like a null pointer or some
othe bug. Will the system prop be left around?
o how do you handle synchronization of 2 connects at basically the same
time?
V.Narayanan (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
>
> V.Narayanan updated DERBY-700:
> ------------------------------
>
> Attachment: DERBY-700.diff
> DERBY-700.stat
>
> Hi,
>
> We could solve this problem by setting a System property before booting a database and checking for the property during subsequent boots. When the database is shutdown we set the property to false. For example when we boot a database named mydb then we set the property derby.dblock.mydb = true. Now during subsequent boots we could check for this system variable and if it is set to true throw an exception. During the shutdown of the database we set this variable to false. I tried an attempt along this line in the attached patch.
>
> I HAVE NOT run the patch with security manager enabled. The sample repro attached with this issue passes with this fix.
>
> Pls note that the patch is not for a commit but is just to represent what I have in mind as a solution, in the form of code.
>
> thanx
> Narayanan
>
>
>>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, DualBootRepro.java, DualBootRepro2.zip
>>
>>
>>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.
>
>
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "V.Narayanan (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
V.Narayanan updated DERBY-700:
------------------------------
Attachment: DERBY-700.diff
DERBY-700.stat
Hi,
We could solve this problem by setting a System property before booting a database and checking for the property during subsequent boots. When the database is shutdown we set the property to false. For example when we boot a database named mydb then we set the property derby.dblock.mydb = true. Now during subsequent boots we could check for this system variable and if it is set to true throw an exception. During the shutdown of the database we set this variable to false. I tried an attempt along this line in the attached patch.
I HAVE NOT run the patch with security manager enabled. The sample repro attached with this issue passes with this fix.
Pls note that the patch is not for a commit but is just to represent what I have in mind as a solution, in the form of code.
thanx
Narayanan
> 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, DualBootRepro.java, DualBootRepro2.zip
>
>
> 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
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503950 ]
Kathey Marsden commented on DERBY-700:
--------------------------------------
I have been unable to figure out exactly what the permission issue is when running with security manager and jars. I did find that it was corrected by giving AllPermissions to derbyTesting.jar. I am thinking therfore that the issue is with the test and not the change itself. I would like to go ahead and checkin the change, disabling security manager for the jars and file another issue to correct that problem. Reviews welcome and let me know if anyone has objections to going ahead and checking in the change. Substantive changes from the initial patch are:
- Fix intermittent NPE
- Fix problem with dual boot with many threads, by expanding the synchronization to include the full privJBMSLockOnDB
- Log warning not fail if System Property permission is not granted instead of failing.
Kathey
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt, 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, 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740660#action_12740660 ]
Rick Hillegas commented on DERBY-700:
-------------------------------------
> Was there consideration given to bakcporting the fix to 1.5, perhaps even with a different default for sun.nio.ch.disableSystemWideOverlappingFileLockCheck?
I believe so. I think that proposal was rejected because the fix would introduce a compatibility change within a major version. The barrier to compatibility changes seems to be higher within major versions than between them. I suppose we could lobby to have that decision revisited but I doubt we would make much headway. The compatibility policy seems sensible to me.
> 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Suresh Thalamati (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484550 ]
Suresh Thalamati commented on DERBY-700:
----------------------------------------
While reading comments for this issue yet again, noticed Rick mentioned long
time ago , it might be possible to make Derby jdbc driver hold a state that
is global to jvm, not specific to a class loader. Is that how it really works
even if the user loads the driver using class loaders ?
Basically , is it possible to make org.apache.derby.jdbc.EmbeddedDriver.java
statically initialize an JVMID(a UUID) that can be accessed from any class loader ?
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Priority: Critical
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-700:
---------------------------------
Attachment: derby.log
When the multithreaded failure occurs there is an NPE accessing the lockfile. Attaching the derby.log.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Attachments: DERBY-700.diff, DERBY-700.stat, 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.log, derby700_singleproperty_v1.diff, derby700_singleproperty_v1.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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706621#action_12706621 ]
Kathey Marsden commented on DERBY-700:
--------------------------------------
I did some testing with the thread name idea (just in a separate stand-alone program) and found that it would probably be workable. Performance wasn't bad. It seemed to take only 16 milliseconds on my machine to iterate through 1000 thread names and synchronizing on an interned string seemed to work across ClassLoaders but ...
1) It would require RuntimePermissions getStackTrace and modifyThreadGroup to derby.jar, which seem like pretty powerful additions to our permissions requirements.
2) I was looking back at Suresh's original implmentation (using the system property) and found that solution actually still holds promise. There was just an issue with synchronization which needs to be resolved. This solution wouldn't collide with any effort to consolidate the daemon threads and we already have this permission requirement documented, so I think this is a cleaner solution that should be revisited.
I'll take a look again at the old patch and try to figure out why the synchronization expansion was required and how to avoid it.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> 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)
> 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren updated DERBY-700:
-------------------------------------
Derby Info: [Existing Application Impact, Release Note Needed] (was: [Release Note Needed, Existing Application Impact])
Fix Version/s: (was: 10.3.0.0)
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Suresh Thalamati <su...@gmail.com>.
In addition to that, there is also a jvm bug related to this call,
which can lead to memory leaks.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4513817
I had too much fun tracking that leak a while ago.
-suresh
Mike Matrigali wrote:
> yes, I believe it does not work if you kill the JVM. I think it also
> did not work if you call System.exit(), but I am don't remember that
> exactly. At least that use to be the case.
>
> Bryan Pendleton wrote:
>
>> Mike Matrigali wrote:
>>
>>> 2) determine if the existing lock is false, ie. the creating process
>>> exited without cleaning up the lock file.
>>
>>
>>
>> Is the reason that this is hard because File.deleteOnExit() is not
>> reliable?
>>
>> thanks,
>>
>> bryan
>>
>>
>>
>>
>>
>
>
Re: [jira] Commented: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Mike Matrigali <mi...@sbcglobal.net>.
yes, I believe it does not work if you kill the JVM. I think it also
did not work if you call System.exit(), but I am don't remember that
exactly. At least that use to be the case.
Bryan Pendleton wrote:
> Mike Matrigali wrote:
>
>> 2) determine if the existing lock is false, ie. the creating process
>> exited without cleaning up the lock file.
>
>
> Is the reason that this is hard because File.deleteOnExit() is not
> reliable?
>
> thanks,
>
> bryan
>
>
>
>
>
Re: [jira] Commented: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Bryan Pendleton <bp...@amberpoint.com>.
Mike Matrigali wrote:
> 2) determine if the existing lock is false, ie. the creating process
> exited without cleaning up the lock file.
Is the reason that this is hard because File.deleteOnExit() is not reliable?
thanks,
bryan
Re: [jira] Commented: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Suresh Thalamati <su...@gmail.com>.
I think pid's are unique at a given moment, so using the process id
might work if Java provides a way to get a PID of process.
But I am not so sure how to generate such a unique id store it in
system property/any where else without hitting classical race
condition problems. I don't think it is possible to TEST/SET a system
property in one instruction.
Assuming such a race condition is rare and it is ok if that case is
not handled correctly, System properties can not be set under
security manager without special permission, I wonder if users
typically give such permissions.
Mike : Why do we need two unique id's? I could not follow why one
needs check class loader ID part ? I thought db boot just need to
check if the lock that we are getting is not already acquired by the
JVM through some other class loader.
Thanks
-suresh
Mike Matrigali wrote:
> For the generic 2 JVM problem we considered a process id scheme, but
> gave up when we could not find encough pure java support. There
> are actually 2 issues:
> 1) enforce the lock
> 2) determine if the existing lock is false, ie. the creating process
> exited without cleaning up the lock file.
>
> Until jdk1.4.2 and file locking we suffered from not being able to
> reliably implement #2. We had 2 options, either assume the lock file
> was valid and force someone to clean up the lock file or go ahead and
> boot while logging an error message. Because it was so easy to leave
> the lock file around we did the error message approach. There was
> a property users could enable to force a hard error if the lock file
> was around.
>
> So the process id approach needs the following jvm support, if using
> the traditional lock file approach:
> 1) some way to uniquely identify a running JVM instance
> 2) some way to identify if that JVM is running
> We are looking for a pure java solution. I just checked the java 1.4.2
> System interface and no portable solution jumped out at me.
>
> But having said that, maybe the dual class loader issue can be treated
> as a secondary locking issue - an additional lock requested before the
> existing cross process locking scheme (which does work, pure java across
> all jvm's >= 1.4.2). I think rather than process
> id we may
> just need to figure out if 2 class loaders from the SAME jvm are trying
> to access the file. This may be an easier problem to solve. I think
> there is some solution to be had using system properties to share
> information across the class loaders. Maybe something like:
>
> o the monitor sets a system property to a UUID which uniquely identifies
> the JVM it is running in. If the property exists already no work is
> done.
>
> o the monitor also creates a unique id for it's existence in the
> classloader.
>
> o db boot now checks the uuid.dat file in the db directory and sees if
> the lock is owned by anyone, and if so is it owned by this classloader
> as identified by the monitor unique id.
>
> o Question is how to tell if the existing lock file has been falsely
> left around by an exited class loader? I assume there is no way to ask
> the JVM if classloader X exists. Can we just count on monitor code to
> do the right thing with the lock file in most cases and in the case of
> JVM failure we won't be looking at that lock file anyway?
>
> Bryan Pendleton wrote:
>
>
>>Suresh Thalamati wrote:
>>
>>
>>>Any ideas to fix this problem ?
>>
>>
>>What if you included some additional information in the lock files,
>>and then changed the locking algorithm so that it considered more
>>than just the presence or absence of the lock file, and whether it
>>could be locked successfully or not.
>>
>>For example, in traditional Unix programming, one would put the
>>process ID of the process which was locking the thing into the file,
>>either in the contents of the file or in the name of the file.
>>
>>That way, another process which came along and discovered the lock
>>file could know not only that some other process was trying to lock
>>the object, but also the process ID of that process.
>>
>>To adapt this algorithm to your case, you would need some sort of
>>unique identifier for each class loader. Then, class loader A in the
>>VM would encounter the lock file, and would see that class loader B
>>in that VM had created the lock file, and would know that the database
>>was locked and a lock error should be returned.
>>
>>In pseudocode:
>>
>> if (file exists &&
>> I am able to lock the file &&
>> (the file was written by a different process ||
>> the file was written by a different class-loader))
>> then
>> the database is locked, return lock error
>>
>>Does this work?
>>
>>thanks,
>>
>>bryan
>>
>>
>>
>
>
Re: [jira] Commented: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Mike Matrigali <mi...@sbcglobal.net>.
For the generic 2 JVM problem we considered a process id scheme, but
gave up when we could not find encough pure java support. There
are actually 2 issues:
1) enforce the lock
2) determine if the existing lock is false, ie. the creating process
exited without cleaning up the lock file.
Until jdk1.4.2 and file locking we suffered from not being able to
reliably implement #2. We had 2 options, either assume the lock file
was valid and force someone to clean up the lock file or go ahead and
boot while logging an error message. Because it was so easy to leave
the lock file around we did the error message approach. There was
a property users could enable to force a hard error if the lock file
was around.
So the process id approach needs the following jvm support, if using
the traditional lock file approach:
1) some way to uniquely identify a running JVM instance
2) some way to identify if that JVM is running
We are looking for a pure java solution. I just checked the java 1.4.2
System interface and no portable solution jumped out at me.
But having said that, maybe the dual class loader issue can be treated
as a secondary locking issue - an additional lock requested before the
existing cross process locking scheme (which does work, pure java across
all jvm's >= 1.4.2). I think rather than process
id we may
just need to figure out if 2 class loaders from the SAME jvm are trying
to access the file. This may be an easier problem to solve. I think
there is some solution to be had using system properties to share
information across the class loaders. Maybe something like:
o the monitor sets a system property to a UUID which uniquely identifies
the JVM it is running in. If the property exists already no work is
done.
o the monitor also creates a unique id for it's existence in the
classloader.
o db boot now checks the uuid.dat file in the db directory and sees if
the lock is owned by anyone, and if so is it owned by this classloader
as identified by the monitor unique id.
o Question is how to tell if the existing lock file has been falsely
left around by an exited class loader? I assume there is no way to ask
the JVM if classloader X exists. Can we just count on monitor code to
do the right thing with the lock file in most cases and in the case of
JVM failure we won't be looking at that lock file anyway?
Bryan Pendleton wrote:
> Suresh Thalamati wrote:
>
>> Any ideas to fix this problem ?
>
>
> What if you included some additional information in the lock files,
> and then changed the locking algorithm so that it considered more
> than just the presence or absence of the lock file, and whether it
> could be locked successfully or not.
>
> For example, in traditional Unix programming, one would put the
> process ID of the process which was locking the thing into the file,
> either in the contents of the file or in the name of the file.
>
> That way, another process which came along and discovered the lock
> file could know not only that some other process was trying to lock
> the object, but also the process ID of that process.
>
> To adapt this algorithm to your case, you would need some sort of
> unique identifier for each class loader. Then, class loader A in the
> VM would encounter the lock file, and would see that class loader B
> in that VM had created the lock file, and would know that the database
> was locked and a lock error should be returned.
>
> In pseudocode:
>
> if (file exists &&
> I am able to lock the file &&
> (the file was written by a different process ||
> the file was written by a different class-loader))
> then
> the database is locked, return lock error
>
> Does this work?
>
> thanks,
>
> bryan
>
>
>
Re: [jira] Commented: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Bryan Pendleton <bp...@amberpoint.com>.
Suresh Thalamati wrote:
> Any ideas to fix this problem ?
What if you included some additional information in the lock files,
and then changed the locking algorithm so that it considered more
than just the presence or absence of the lock file, and whether it
could be locked successfully or not.
For example, in traditional Unix programming, one would put the
process ID of the process which was locking the thing into the file,
either in the contents of the file or in the name of the file.
That way, another process which came along and discovered the lock
file could know not only that some other process was trying to lock
the object, but also the process ID of that process.
To adapt this algorithm to your case, you would need some sort of
unique identifier for each class loader. Then, class loader A in the
VM would encounter the lock file, and would see that class loader B
in that VM had created the lock file, and would know that the database
was locked and a lock error should be returned.
In pseudocode:
if (file exists &&
I am able to lock the file &&
(the file was written by a different process ||
the file was written by a different class-loader))
then
the database is locked, return lock error
Does this work?
thanks,
bryan
Re: [jira] Commented: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Suresh Thalamati <su...@gmail.com>.
On windows old lock mechanism(if a file is open, it can not be deleted
until it is closed..) is used always to prevent the dual boot of the
same database, that is why it works fine even with multiple class
loaders. Java File lock mechanism is used only on systems where one
can delete the file even when it is opened. That is why we are seeing
this problem on Unix. As I mentioned in my earlier comments Java File
Lock mechanism can not be used to prevent dual boot with in the same
JVM unless if a single instant of FileChannel on the lock file is used
across the whole JVM then OverLappingFileLock exception can be used.
Otherwise
FileLocks can not be used to control the access to a file.
java doc on file lock:
"File locks are held on behalf of the entire Java virtual machine.
They are not suitable for controlling access to a file by multiple
threads within the same virtual machine."
Any ideas to fix this problem ?
Thanks
suresht
Mike Matrigali wrote:
> Do you happen to know why it works on windows? Is the file lock
> behavior different, or is the old windows-only locking method
> automatically kicking in?
>
> Suresh Thalamati (JIRA) wrote:
>
>> [
>> http://issues.apache.org/jira/browse/DERBY-700?page=comments#action_12363492
>> ]
>> Suresh Thalamati commented on DERBY-700:
>> ----------------------------------------
>>
>> After doing bit of testing realized checking for
>> OverlappingFileLockException does not work. This exception is
>> reliable only if the same file channel instance is used., With
>> multiple class loaders I don't know how it is possible to have a
>> sigle file channel object.
>> On Linux , one can acquire the lock on the same region using
>> diferent file channels on the same file.
>> Realated info from the java docs:
>> java.nio.channel.FileLock ,On some systems, closing a channel releases
>> all locks held by the Java virtual machine on the underlying file
>> regardless of whether the locks were acquired via that channel or via
>> another channel open on the same file. It is strongly recommended
>> that, within a program, a unique channel be used to acquire all locks
>> on any given file.
>>
>>
>>
>>
>>> 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
>>> Type: Bug
>>> Components: Store
>>> 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
>>> Attachments: DualBootRepro.java, DualBootRepro2.zip
>>>
>>> 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.
>>
>>
>>
>
>
Re: [jira] Commented: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Do you happen to know why it works on windows? Is the file lock
behavior different, or is the old windows-only locking method
automatically kicking in?
Suresh Thalamati (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-700?page=comments#action_12363492 ]
>
> Suresh Thalamati commented on DERBY-700:
> ----------------------------------------
>
> After doing bit of testing realized checking for OverlappingFileLockException does not work. This exception is reliable only if the same file channel instance is used., With multiple class loaders
> I don't know how it is possible to have a sigle file channel object.
>
> On Linux , one can acquire the lock on the same region using diferent file channels on the same file.
>
> Realated info from the java docs:
> java.nio.channel.FileLock
> ,On some systems, closing a channel releases all locks held by the Java virtual machine on the underlying file regardless of whether the locks were acquired via that channel or via another channel open on the same file. It is strongly recommended that, within a program, a unique channel be used to acquire all locks on any given file.
>
>
>
>
>>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
>> Type: Bug
>> Components: Store
>> 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
>> Attachments: DualBootRepro.java, DualBootRepro2.zip
>>
>>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.
>
>
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Suresh Thalamati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=comments#action_12363492 ]
Suresh Thalamati commented on DERBY-700:
----------------------------------------
After doing bit of testing realized checking for OverlappingFileLockException does not work. This exception is reliable only if the same file channel instance is used., With multiple class loaders
I don't know how it is possible to have a sigle file channel object.
On Linux , one can acquire the lock on the same region using diferent file channels on the same file.
Realated info from the java docs:
java.nio.channel.FileLock
,On some systems, closing a channel releases all locks held by the Java virtual machine on the underlying file regardless of whether the locks were acquired via that channel or via another channel open on the same file. It is strongly recommended that, within a program, a unique channel be used to acquire all locks on any given file.
> 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
> Type: Bug
> Components: Store
> 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
> Attachments: DualBootRepro.java, DualBootRepro2.zip
>
> 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
[jira] Issue Comment Edited: (DERBY-700) Derby does not prevent
dual boot of database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740196#action_12740196 ]
Rick Hillegas edited comment on DERBY-700 at 8/6/09 11:57 AM:
--------------------------------------------------------------
It appears to me that a workaround for this bug is to upgrade to Java 6. I am attaching a slightly revised version of the repro, DualBootRepro.java (this revision contains all of the helper classes needed to create the failure scenario). I see failures on the following platforms:
Apple Java 5 on Mac OS X
Sun Java 5 on Ubuntu Linux
IBM Java 5 on Ubuntu Linux
Happily, however, the second boot fails and raises java.nio.channels.OverlappingFileLockException on the following platforms:
Apple Java 6 beta on Mac OS X
Sun Java 6 on Ubuntu Linux
IBM Java 6 on Ubuntu Linux
Admittedly, that's a graceless failure. However, I think it should prevent the database from being corrupted and it's worth recommending an upgrade to Java 6 for users who encounter this bug.
was (Author: rhillegas):
It appears to me that a workaround for this bug is to upgrade to Java 6. I am attaching a slightly revised version of the repro, DualBootRepro.java (this revision contains all of the helper classes needed to create the failure scenario). I see failures on the following platforms:
Apple Java 5 on Mac OS X
Sun Java 5 on Ubuntu Linux
IBM Java 5 on Ubuntu Linux
Happily, however, the second boot fails and raises java.nio.channels.OverlappingFileLockException on the following platforms:
Apple Java 6 beta on Mac OS X
Sun Java 6 on Ubuntu Linux
IBM Java 5 on Ubuntu Linux
Admittedly, that's a graceless failure. However, I think it should prevent the database from being corrupted and it's worth recommending an upgrade to Java 6 for users who encounter this bug.
> 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.
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
Posted by Francois Orsini <fr...@gmail.com>.
Yes, you are right - This is quite a corner case anyway and if it does
happen, proper action (such as removing the file physically) would have to
be done manually as in the case today (if running pre-1.4.2) which should
not be the case with 10.3 (if am not mistaken) - Hence, Derby will remove a
db lock file that has been kept around and recreate a new one the next time
it opens the DB _IF_ that one is not already locked....I suppose this would
apply there too...
On 5/31/07, Kathey Marsden <km...@sbcglobal.net> wrote:
>
> Kathey Marsden wrote:
> > Francois Orsini wrote:
> >> I haven't looked at the absolute latest changes and I was wondering
> >> if the case of a database being opened in a separate classloader and
> >> not having been shut down properly (due to unexpected exception in
> >> the application) could impede some other classloader to open the very
> >> same database due to the state of the dbex.lck file, not having been
> >> changed due to the exception in the other classloarder?
> > I think this is a legitimate concern (assuming I can get the thing
> > working to prevent dual boot) as the System property and file contents
> > would still match. I'm not quite sure how to ensure proper cleanup in
> > this case. There once was a request that we have an option that the
> > database shutdown if there were no connections. That's about the only
> > way I can see to resolve it.
> Well the good news is I got the synchronization working. On the cleanup
> issue, I have been thinking about this case and I think that typically
> an App Server is going to have one classloader per JDBC Provider. For
> example they might have two versions of Derby with different
> classloaders accessing two different databases. Typically if the
> application is restarted it would be in the same Classloader I think.
> Normal usage would not be to have two different Classloaders accessing
> the same database. For that network server would make more sense.
>
> Kathey
>
>
>
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Kathey Marsden wrote:
> Kathey Marsden wrote:
>> Francois Orsini wrote:
>>> I haven't looked at the absolute latest changes and I was wondering
>>> if the case of a database being opened in a separate classloader and
>>> not having been shut down properly (due to unexpected exception in
>>> the application) could impede some other classloader to open the very
>>> same database due to the state of the dbex.lck file, not having been
>>> changed due to the exception in the other classloarder?
>> I think this is a legitimate concern (assuming I can get the thing
>> working to prevent dual boot) as the System property and file contents
>> would still match. I'm not quite sure how to ensure proper cleanup in
>> this case. There once was a request that we have an option that the
>> database shutdown if there were no connections. That's about the only
>> way I can see to resolve it.
> Well the good news is I got the synchronization working. On the cleanup
> issue, I have been thinking about this case and I think that typically
> an App Server is going to have one classloader per JDBC Provider. For
> example they might have two versions of Derby with different
> classloaders accessing two different databases. Typically if the
> application is restarted it would be in the same Classloader I think.
> Normal usage would not be to have two different Classloaders accessing
> the same database. For that network server would make more sense.
I think the key is to outline the intended environments Derby is meant
to support/run well in. DERBY-700 goal is to prevent corruption in a
case where Derby is not meant to run - just as Derby already has support
for preventing access from multiple JVMs, it's goal is not to encourage
users to use Embedded Derby in mulitple classloaders against the same
JVM.
Embedded Derby is intended to be run where access to a single derby
database is always intended to be from a single class loader from a
single JVM. In order to provide correct locking and expected database
caching performance Embedded Derby uses memory that must be directly
accessible to all threads accessing the database. The current
implementation of Embedded Derby can only support this when accesses
are always channeled to a single classloader within a single JVM.
Network Derby is intended to be run in all other cases:
multiple machines: The obvious case is accessing a single derby
database from separate machines
multiple JVMs: The slightly less obvious is accessing derby from
separate JVM's on same machine.
multiple classloaders within same JVM:
And unfornately not obvious at all is that it is
required to access a single derby database started
in one classloader in a JVM from any any other
classloader in the JVM.
Note all these restrictions are about running Derby against a given
database. There are no restrictions about running 2 different
databases in 2 different class loaders, and these Derby instances
can be different versions of the Derby software.
>
> Kathey
>
>
>
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Kathey Marsden <km...@sbcglobal.net>.
Kathey Marsden wrote:
> Francois Orsini wrote:
>> I haven't looked at the absolute latest changes and I was wondering
>> if the case of a database being opened in a separate classloader and
>> not having been shut down properly (due to unexpected exception in
>> the application) could impede some other classloader to open the very
>> same database due to the state of the dbex.lck file, not having been
>> changed due to the exception in the other classloarder?
> I think this is a legitimate concern (assuming I can get the thing
> working to prevent dual boot) as the System property and file contents
> would still match. I'm not quite sure how to ensure proper cleanup in
> this case. There once was a request that we have an option that the
> database shutdown if there were no connections. That's about the only
> way I can see to resolve it.
Well the good news is I got the synchronization working. On the cleanup
issue, I have been thinking about this case and I think that typically
an App Server is going to have one classloader per JDBC Provider. For
example they might have two versions of Derby with different
classloaders accessing two different databases. Typically if the
application is restarted it would be in the same Classloader I think.
Normal usage would not be to have two different Classloaders accessing
the same database. For that network server would make more sense.
Kathey
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Kathey Marsden <km...@sbcglobal.net>.
Francois Orsini wrote:
> I haven't looked at the absolute latest changes and I was wondering if
> the case of a database being opened in a separate classloader and not
> having been shut down properly (due to unexpected exception in the
> application) could impede some other classloader to open the very same
> database due to the state of the dbex.lck file, not having been
> changed due to the exception in the other classloarder?
I think this is a legitimate concern (assuming I can get the thing
working to prevent dual boot) as the System property and file contents
would still match. I'm not quite sure how to ensure proper cleanup in
this case. There once was a request that we have an option that the
database shutdown if there were no connections. That's about the only
way I can see to resolve it.
Kathey
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
Posted by Francois Orsini <fr...@gmail.com>.
I haven't looked at the absolute latest changes and I was wondering if the
case of a database being opened in a separate classloader and not having
been shut down properly (due to unexpected exception in the application)
could impede some other classloader to open the very same database due to
the state of the dbex.lck file, not having been changed due to the exception
in the other classloarder?
On 5/30/07, Kathey Marsden <km...@sbcglobal.net> wrote:
>
> Daniel John Debrunner wrote:
> > Kathey Marsden wrote:
> >> Daniel John Debrunner wrote:
> >>>
> >>> Actually string constants are by definition interned, so
> >>> synchronized(DERBY_JVM_ID) is the same as
> >>> synchronized(DERBY_JVM_ID.intern()) since DERBY_JVM_ID is a
> >>> reference to a string constant. Though using intern() wouldn't harm
> >>> and might make the code more readable.
> >>>
> >> Silly question. Would an interned string allow synchronization
> >> across classloaders?
> >> If not, how do I synchronize two threads using different classloaders.
> >> Kathey
> >
> > Yes. The intern() provides a reference that will be identical
> > regardless of any current class loader because the String class will
> > only be loaded once by the jvm. You can google for other folks using
> > the same trick, or using other objects that are guaranteed to be
> > loaded once such as Integer.class, Integer.TYPE etc.
> >
> So I will assume then that my problem is
>
> 2) Since getting the exFileLock is not within the synchronized code. It
> is possible that the state of the dbex.lck file on disk changes before
> the boot.
>
> I'll approach it from that angle.
>
> Kathey
>
>
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Kathey Marsden <km...@sbcglobal.net>.
Daniel John Debrunner wrote:
> Kathey Marsden wrote:
>> Daniel John Debrunner wrote:
>>>
>>> Actually string constants are by definition interned, so
>>> synchronized(DERBY_JVM_ID) is the same as
>>> synchronized(DERBY_JVM_ID.intern()) since DERBY_JVM_ID is a
>>> reference to a string constant. Though using intern() wouldn't harm
>>> and might make the code more readable.
>>>
>> Silly question. Would an interned string allow synchronization
>> across classloaders?
>> If not, how do I synchronize two threads using different classloaders.
>> Kathey
>
> Yes. The intern() provides a reference that will be identical
> regardless of any current class loader because the String class will
> only be loaded once by the jvm. You can google for other folks using
> the same trick, or using other objects that are guaranteed to be
> loaded once such as Integer.class, Integer.TYPE etc.
>
So I will assume then that my problem is
2) Since getting the exFileLock is not within the synchronized code. It
is possible that the state of the dbex.lck file on disk changes before
the boot.
I'll approach it from that angle.
Kathey
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Daniel John Debrunner <dj...@apache.org>.
Kathey Marsden wrote:
> Daniel John Debrunner wrote:
>>
>> Actually string constants are by definition interned, so
>> synchronized(DERBY_JVM_ID) is the same as
>> synchronized(DERBY_JVM_ID.intern()) since DERBY_JVM_ID is a reference
>> to a string constant. Though using intern() wouldn't harm and might
>> make the code more readable.
>>
> Silly question. Would an interned string allow synchronization across
> classloaders?
> If not, how do I synchronize two threads using different classloaders.
> Kathey
Yes. The intern() provides a reference that will be identical regardless
of any current class loader because the String class will only be loaded
once by the jvm. You can google for other folks using the same trick, or
using other objects that are guaranteed to be loaded once such as
Integer.class, Integer.TYPE etc.
Dan.
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Kathey Marsden <km...@sbcglobal.net>.
Daniel John Debrunner wrote:
>
> Actually string constants are by definition interned, so
> synchronized(DERBY_JVM_ID) is the same as
> synchronized(DERBY_JVM_ID.intern()) since DERBY_JVM_ID is a reference
> to a string constant. Though using intern() wouldn't harm and might
> make the code more readable.
>
Silly question. Would an interned string allow synchronization across
classloaders?
If not, how do I synchronize two threads using different classloaders.
Kathey
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Daniel John Debrunner <dj...@apache.org>.
Mike Matrigali wrote:
>
>
> Kathey Marsden (JIRA) wrote:
>> [
>> https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> Kathey Marsden updated DERBY-700:
>> ---------------------------------
>>
>> Attachment: derby-700_with_NPE_fix_diff.txt
> If string.intern()sync does not work then following comment does not
> matter.
>
> It looks like code does synchronized(DERBY_JVM_ID) but I think it wants
> to do synchronized on intern of that string.
Actually string constants are by definition interned, so
synchronized(DERBY_JVM_ID) is the same as
synchronized(DERBY_JVM_ID.intern()) since DERBY_JVM_ID is a reference to
a string constant. Though using intern() wouldn't harm and might make
the code more readable.
Dan.
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Kathey Marsden (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Kathey Marsden updated DERBY-700:
> ---------------------------------
>
> Attachment: derby-700_with_NPE_fix_diff.txt
If string.intern()sync does not work then following comment does not matter.
It looks like code does synchronized(DERBY_JVM_ID) but I think it wants
to do synchronized on intern of that string.
>
> Attached is a patch that fixes the NPE, but there are still issues with the multithreaded test. Sometimes with 9 or more threads in startConcurrentDatabaseBoots we get dual boot without any message to the derby.log. I think there is one of two issues here:
>
> 1) There is no synchronization across classloaders, so even though we synchronize on the databaseName() it is not useful when two threads from different ClassLoaders come into the synchronized code.
>
> 2) Since getting the exFileLock is not within the synchronized code. It is possible that the state of the dbex.lck file on disk changes before the boot.
>
> I am not sure how to resolve these issues, especially 1. I'd appreciate any advice on the issue.
>
> Thanks
>
> Kathey
>
>
>
>
>>Derby does not prevent dual boot of database from different classloaders on Linux
>>---------------------------------------------------------------------------------
>>
>> Key: DERBY-700
>> URL: https://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
>> Assignee: Kathey Marsden
>> Priority: Critical
>> Attachments: DERBY-700.diff, DERBY-700.stat, 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, 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.
>
>
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Kathey Marsden (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Kathey Marsden updated DERBY-700:
> ---------------------------------
>
> Attachment: derby-700_with_NPE_fix_diff.txt
>
> Attached is a patch that fixes the NPE, but there are still issues with the multithreaded test. Sometimes with 9 or more threads in startConcurrentDatabaseBoots we get dual boot without any message to the derby.log. I think there is one of two issues here:
>
> 1) There is no synchronization across classloaders, so even though we synchronize on the databaseName() it is not useful when two threads from different ClassLoaders come into the synchronized code.
>
Not sure what you are saying here. Do you believe the technique of
synchronizing on the intern of a String does not work across
classloaders? If that does not work, I agree that the the change
is not going to work.
> 2) Since getting the exFileLock is not within the synchronized code. It is possible that the state of the dbex.lck file on disk changes before the boot.
>
> I am not sure how to resolve these issues, especially 1. I'd appreciate any advice on the issue.
>
> Thanks
>
> Kathey
>
>
>
>
>>Derby does not prevent dual boot of database from different classloaders on Linux
>>---------------------------------------------------------------------------------
>>
>> Key: DERBY-700
>> URL: https://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
>> Assignee: Kathey Marsden
>> Priority: Critical
>> Attachments: DERBY-700.diff, DERBY-700.stat, 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, 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.
>
>
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-700:
---------------------------------
Attachment: derby-700_with_NPE_fix_diff.txt
Attached is a patch that fixes the NPE, but there are still issues with the multithreaded test. Sometimes with 9 or more threads in startConcurrentDatabaseBoots we get dual boot without any message to the derby.log. I think there is one of two issues here:
1) There is no synchronization across classloaders, so even though we synchronize on the databaseName() it is not useful when two threads from different ClassLoaders come into the synchronized code.
2) Since getting the exFileLock is not within the synchronized code. It is possible that the state of the dbex.lck file on disk changes before the boot.
I am not sure how to resolve these issues, especially 1. I'd appreciate any advice on the issue.
Thanks
Kathey
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Attachments: DERBY-700.diff, DERBY-700.stat, 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, 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744593#action_12744593 ]
Rick Hillegas commented on DERBY-700:
-------------------------------------
Ported 805448 from trunk to 10.3 branch at subversion revision 805486.
> 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-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498037 ]
Kathey Marsden commented on DERBY-700:
--------------------------------------
Thanks Suresh for the patch! I was wondering, why do we need setContextClassLoader privileges for derby.jar with the change?
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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: Kathey Marsden
> Priority: Critical
> 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, derby700_singleproperty_v1.diff, derby700_singleproperty_v1.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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744938#action_12744938 ]
Knut Anders Hatlen commented on DERBY-700:
------------------------------------------
ManagementMBeanTest started failing in the Tinderbox (trunk and 10.4) after the check-in:
http://dbtg.foundry.sun.com/derby/test/tinderbox_10.4_16/jvm1.6/testing/Limited/testSummary-805541.html
http://dbtg.foundry.sun.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-805576.html
> 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-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744946#action_12744946 ]
Knut Anders Hatlen commented on DERBY-700:
------------------------------------------
I noticed this in the new test (ClassLoaderBootTest):
- it would be good to null out the three ClassLoader fields in tearDown() so that the class loaders and the classes they have loaded can be garbage collected (otherwise they'll stay in memory until the full JUnit run has finished)
- the decorateSQL() method creates a table which is said to be used to test export, but I don't see any code for testing export
- the test cases are wrapped in try {...} catch (SQLException se) { dumpSQLException(se); }. Won't this prevent the reporting of the exception in JUnit? Better to let the exceptions be thrown and handled by the framework?
- the methods getFileWhichLoadedClass(Class) and getURL(File) have no callers
> 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-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, 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.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-700:
---------------------------------
Attachment: derby-700_06_19_2007
Mike asked me to post the patch that has changes from Dan's first round of review comments but does not have the move of getIntraJVMDbLock to DirFile4. This is not for commit
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743395#action_12743395 ]
Rick Hillegas commented on DERBY-700:
-------------------------------------
Thanks, Mike. I will add that comment. I will also add a test case. For the record, the regression tests ran cleanly for me.
> 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-01-aa-catchOverlappingFileLockException.diff, 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.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509170 ]
Daniel John Debrunner commented on DERBY-700:
---------------------------------------------
Expanding the synchronization "because it works" concerns me greatly as an engineering approach to addressing a synchronization issue.
The purpose of the synchronization was intended to protect a small window while a unique identifier was being written into a file (exFileLock in privGetJBMSLockOnDB) used for lock control.
Expanding this synchronization is now also protecting the writing of a *different* file (fileLock in privGetJBMSLockOnDB), but why is that needed?
Especially when the system has to handle multiple jvm's writing to that same file, when object synchronization doesn't help.
It maybe that the current locking across doesn't really work and there are windows where multiple jvms booting the same database at the same time would succeed when they should fail. E.g. the locking works correctly when two jvms boot the same database one after the other (ie the second would fail) but not when they concurrently boot the same db. Maybe your test is exposing that and so the synchronization is required, but then it doesn't address the cross jvm issue.
The locking of database boot is already complicated and adding the new (required) mechanism for cross-class loader complicates it further.
It would be good to have a clear description of how the various schemes work and interact with each other. WIth that, one could then more easily determine what synchronization is required *and why*.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.3.0.0
>
> 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Overall I prefer your proposal to mine, assuming it works. Have you
had a chance to prototype this on a non-windows system? I couldn't
find a problem in the pseudo-code from reading it.
My concerns are:
1) Can we count on class finalizers? What, if any situations are there
that should have released the lock but we missed because the class
finalizer was not run? At least the result of this problem is a
false positive rather than a corrupt db.
2) Is it ok to require the new system properties/permissions - see
below.
3) What level JVM do we require for this solution, off hand I was
wondering if we are counting a specific level for fine grained security
permision for the system property setting.
Other comments below
Suresh Thalamati (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484998 ]
>
> Suresh Thalamati commented on DERBY-700:
> ----------------------------------------
>
> Thanks a lot for summarizing the problems and possible solutions
> for this issue, Mike. I think the timer base solution you mentioned
> might work, but I am not comfortable with a timer based solution. As you
> mentioned, users might complain about the background writes, and also
> I think configuring N to the right value to differentiate false
> negatives/positives boots going to be hard. It will depend on the load
> and the machine configuration (no of cpus ) ..etc.
>
> I was trying to find alternative solutions, without much success. Only
> solution I could come up with involves using a system property. I
> understand, earlier we discussed using the system properties and it was
> decided as not a such a good idea. But considering there are NO other
> better solutions found for this problem, so far. I was think having one
> property to maintain a JVMID may not be so bad, user just need to give
> security permission to set one property, i.e if what I
> describe below actually works!
>
> I would really appreciate any suggestions/feedback for this solution .
>
> My understanding is a solution to this problem need to solve primarily
> following three issues:
>
> 1) Maintaining a state that a database is already booted, if the database
> if booted successfully.
> 2) Change the state to NOT_BOOTED, if it is not booted any more because of a
> a) Shutdown of the database
> b) Class loader that booted the db is garbage collected.
> c) JVM exited.
>
> 3) synchronization across class loaders.
>
> Pseudo code below that attempts to solve this problems by making the
> following Assumptions :
>
> 1) It is ok to use ONE system property "derby.storage.jvmid" to identify
> a jvm instance id.
This seems reasonable to me. It really is a system property that is
meant to be shared across class loaders. Unlike some of our system
properties which would be nice to isolate to particular class loaders.
> 2) It is ok to use interned strings to synchronize across class loader.
I don't see any problem with this, though it might be nice to have a
test that verifies this works. It seems sort of a tricky thing to count
on, so would be nice to verify it works on whatever jvm we run tests on.
It is the only way so far I have thought of to synchronize safely across
class loader.
> 3) It is ok to call getCanonicalPath(), i think this may require permission
> for "user.dir" property if it is not already required. Other solution
> may be to assign an ID string on create of the DB and user that for
> DB level synchronization.
I don't know much about this issue. Any thoughts from people looking
at increased security in 10.3?
> 4) It is ok to rely on the class finalizer to cleanup db lock state,
> when the database is NOT any more because the loader that booted
> the database is garbage collected.
I can't think of any other way, other than the crude timer approach. As
usual be careful not to code a possible deadlock into the finalizer
routine.
>
>
> /*
> Pseudo code to lock the DB to prevent multiple instance of a database running
> concurrently through class loaders in a single instance of jvm or
> multiple instance of jvm.
>
> Note: Following code class is in a separate class just to understand it
> as separate issue , this code should probably go into the
> dataFactory class where current db-locking is done.
> */
> Class DbLock {
>
> private static final String DERYB_JVM_ID = "derby.storage.jvmid";
> private String dbCannonicalPath; // canonical of the db being booted.
> private FileLock fileLock = null;
> private boolean dbLocked = false;
>
> DbLock (String dbCannonicalPath) {
> this.dbCannonicalPath = dbCannonicalPath;
> }
>
> /*
> * get a unique JVM ID
> */
> private getJvmId () {
> // synchronize across class loaders.
> synchronize(DERYB_JVM_ID) {
>
> jvmid = System.getProperty(DERYB_JVM_ID);
> // if jvm id is not already exist, generate one
> // and save it into the "derby.storage.jvmid" system
> // property.
> if (jvmid == null) {
> //generate a new UUID based on the time and IP ..etc.
> jvmid = generateJvmId()
> System.setProperty("derby.storage.jvmid");
> }
> }
> }
>
> /*
> * Lock the db, so that other class loader or
> * another jvm won't be able to boot the same database.
> */
> public lock_db_onboot(String dbCannonicalPath) {
>
> // Get a file Lock on boot() ; // this already works
> fileLock = getFileLock("dbex.lck");
> if (lock == null) {
> // if we don't get lock means , some other jvm already
> // booted it throws ALREADY_BOOTED error.
> throw ALREADY_BOOTED;
> } else {
>
> // file lock can be acquired even if the database is already
> // booted by a different class loader. Check if another class
> // loader has booted the DB. This is done by checking the
> // JVMID written in the dbex.lck file. If the JVMID is same
> // as what is stored in the system property,
> // then database is already booted , throw the error.
> currentJvmId = getJvmId();
> synchronize(dbCannonicalPath) {
> onDisk_JVM_ID = readIdFromDisk() ; // read ID from the dbex.lck file.
> if (OnDisk_JVM_ID == current_jvm_id )
> throw ("DATABASE IS ALREADY BOOTED");
> else{
> dbLocked = true;
> writeId(currentJvmId); //update the dbex.lck file) .
> }
> }
> }
> }
>
>
>
> /*
> * Called on shutdown/garbage collection.
> */
> unlock_db() {
> if (dbLocked) {
> Strinng Ondisk_jvm_id = "-1"; //jvm id should never have been a -1.
> synchronize(dbCannonicalPath) {
> writeIdToDisk(Ondisk_jvm_id); //update the dbex.lck file) .
> }
> releaseFileLock(fileLock);
> dbLocked = false;
> }
> }
>
>
> /*
> * if the db is not shutdown, this method should release
> * the db lock related resources during this class finalization.
> */
> protected void finalize() throws Throwable
> {
> unlock_db();
> }
> }
>
>
>
>
>>Derby does not prevent dual boot of database from different classloaders on Linux
>>---------------------------------------------------------------------------------
>>
>> Key: DERBY-700
>> URL: https://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
>> Priority: Critical
>> 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.
>
>
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Suresh Thalamati (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484998 ]
Suresh Thalamati commented on DERBY-700:
----------------------------------------
Thanks a lot for summarizing the problems and possible solutions
for this issue, Mike. I think the timer base solution you mentioned
might work, but I am not comfortable with a timer based solution. As you
mentioned, users might complain about the background writes, and also
I think configuring N to the right value to differentiate false
negatives/positives boots going to be hard. It will depend on the load
and the machine configuration (no of cpus ) ..etc.
I was trying to find alternative solutions, without much success. Only
solution I could come up with involves using a system property. I
understand, earlier we discussed using the system properties and it was
decided as not a such a good idea. But considering there are NO other
better solutions found for this problem, so far. I was think having one
property to maintain a JVMID may not be so bad, user just need to give
security permission to set one property, i.e if what I
describe below actually works!
I would really appreciate any suggestions/feedback for this solution .
My understanding is a solution to this problem need to solve primarily
following three issues:
1) Maintaining a state that a database is already booted, if the database
if booted successfully.
2) Change the state to NOT_BOOTED, if it is not booted any more because of a
a) Shutdown of the database
b) Class loader that booted the db is garbage collected.
c) JVM exited.
3) synchronization across class loaders.
Pseudo code below that attempts to solve this problems by making the
following Assumptions :
1) It is ok to use ONE system property "derby.storage.jvmid" to identify
a jvm instance id.
2) It is ok to use interned strings to synchronize across class loader.
3) It is ok to call getCanonicalPath(), i think this may require permission
for "user.dir" property if it is not already required. Other solution
may be to assign an ID string on create of the DB and user that for
DB level synchronization.
4) It is ok to rely on the class finalizer to cleanup db lock state,
when the database is NOT any more because the loader that booted
the database is garbage collected.
/*
Pseudo code to lock the DB to prevent multiple instance of a database running
concurrently through class loaders in a single instance of jvm or
multiple instance of jvm.
Note: Following code class is in a separate class just to understand it
as separate issue , this code should probably go into the
dataFactory class where current db-locking is done.
*/
Class DbLock {
private static final String DERYB_JVM_ID = "derby.storage.jvmid";
private String dbCannonicalPath; // canonical of the db being booted.
private FileLock fileLock = null;
private boolean dbLocked = false;
DbLock (String dbCannonicalPath) {
this.dbCannonicalPath = dbCannonicalPath;
}
/*
* get a unique JVM ID
*/
private getJvmId () {
// synchronize across class loaders.
synchronize(DERYB_JVM_ID) {
jvmid = System.getProperty(DERYB_JVM_ID);
// if jvm id is not already exist, generate one
// and save it into the "derby.storage.jvmid" system
// property.
if (jvmid == null) {
//generate a new UUID based on the time and IP ..etc.
jvmid = generateJvmId()
System.setProperty("derby.storage.jvmid");
}
}
}
/*
* Lock the db, so that other class loader or
* another jvm won't be able to boot the same database.
*/
public lock_db_onboot(String dbCannonicalPath) {
// Get a file Lock on boot() ; // this already works
fileLock = getFileLock("dbex.lck");
if (lock == null) {
// if we don't get lock means , some other jvm already
// booted it throws ALREADY_BOOTED error.
throw ALREADY_BOOTED;
} else {
// file lock can be acquired even if the database is already
// booted by a different class loader. Check if another class
// loader has booted the DB. This is done by checking the
// JVMID written in the dbex.lck file. If the JVMID is same
// as what is stored in the system property,
// then database is already booted , throw the error.
currentJvmId = getJvmId();
synchronize(dbCannonicalPath) {
onDisk_JVM_ID = readIdFromDisk() ; // read ID from the dbex.lck file.
if (OnDisk_JVM_ID == current_jvm_id )
throw ("DATABASE IS ALREADY BOOTED");
else{
dbLocked = true;
writeId(currentJvmId); //update the dbex.lck file) .
}
}
}
}
/*
* Called on shutdown/garbage collection.
*/
unlock_db() {
if (dbLocked) {
Strinng Ondisk_jvm_id = "-1"; //jvm id should never have been a -1.
synchronize(dbCannonicalPath) {
writeIdToDisk(Ondisk_jvm_id); //update the dbex.lck file) .
}
releaseFileLock(fileLock);
dbLocked = false;
}
}
/*
* if the db is not shutdown, this method should release
* the db lock related resources during this class finalization.
*/
protected void finalize() throws Throwable
{
unlock_db();
}
}
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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
> Priority: Critical
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-700:
---------------------------------
Derby Info: [Existing Application Impact, Release Note Needed] (was: [Release Note Needed, Existing Application Impact])
Derby Categories: [High Value Fix]
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> 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)
> 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, DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499134 ]
Kathey Marsden commented on DERBY-700:
--------------------------------------
Suresh said
>2) Currently dataDirectory path string is is used for synchronization to
> prevent multiple boots of a database. This may need to be changed to
> the db name.
Why does this need to be changed? If we switched to databaseName might there be potential for duplicate database names? The dataDirectory path seems logical to me.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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: Kathey Marsden
> Priority: Critical
> 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, derby700_singleproperty_v1.diff, derby700_singleproperty_v1.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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499137 ]
Daniel John Debrunner commented on DERBY-700:
---------------------------------------------
The issue with the path is that the canonical path would be needed which requires permission to read system property user.dir, which might not be granted.
The base name of the path ("database name") is easy to obtain and works just as well. The synchronization on this object is very short lived, thus it does not stop two databases with the same name but different paths from booting.
> Derby does not prevent dual boot of database from different classloaders on Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://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: Kathey Marsden
> Priority: Critical
> 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, derby700_singleproperty_v1.diff, derby700_singleproperty_v1.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.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux and Mac OS X
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas reassigned DERBY-700:
-----------------------------------
Assignee: Rick Hillegas
> 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
> Assignee: Rick Hillegas
> Priority: Critical
> Attachments: derby-700-01-aa-catchOverlappingFileLockException.diff, derby-700-01-ab-catchOverlappingFileLockException.diff, derby-700-02-aa-testCleanup.diff, 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.
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Suresh Thalamati <su...@gmail.com>.
I think the scope of file lock is for the whole JVM , not specific to
a class loader. This is what I found in the java doc for
java.nio.channels.FileChannel.tryLock() that is used by the Derby.
"File locks are held on behalf of the entire Java virtual machine.
They are not suitable for controlling access to a file by multiple
threads within the same virtual machine. "
Thanks
-suresht
Mike Matrigali wrote:
> Derby uses java file locking to prevent dual booting, does anyone
> know if there are bugs outstanding with filelocking from 2
> different classloaders in the same jvm.
>
> I suggest anyone looking at this first write a java specific test
> outside of derby to verify that the filelocking behavior that
> Derby depends on works in the particular environment.
>
> Kathey Marsden (JIRA) wrote:
>
>> [ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
>>
>>Kathey Marsden updated DERBY-700:
>>---------------------------------
>>
>> Component: Store
>> Fix Version: (was: 10.1.3.0)
>> 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)
>>
>> was:
>>
>>
>>Sysinfo output.
>>
>>java -cp ./10.1.2.1/derby.jar org.apache.derby.tools.sysinfo
>>------------------ Java Information ------------------
>>Java Version: 1.4.2_08
>>Java Vendor: Sun Microsystems Inc.
>>Java home: /usr/lib/SunJava2-1.4.2/jre
>>Java classpath: ./10.1.2.1/derby.jar
>>OS name: Linux
>>OS architecture: i386
>>OS version: 2.6.5-7.201-smp
>>...
>>java.specification.name: Java Platform API Specification
>>java.specification.version: 1.4
>>--------- Derby Information --------
>>JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
>>[/.../derby.jar] 10.1.2.1 - (330608)
>>------------------------------------------------------
>>----------------- Locale Information -----------------
>>------------------------------------------------------
>>
>>
>>
>>
>>
>>>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
>>> Type: Bug
>>> Components: Store
>>> 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
>>>Attachments: DualBootRepro.java
>>>
>>>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.
>>
>>
>
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Derby uses java file locking to prevent dual booting, does anyone
know if there are bugs outstanding with filelocking from 2
different classloaders in the same jvm.
I suggest anyone looking at this first write a java specific test
outside of derby to verify that the filelocking behavior that
Derby depends on works in the particular environment.
Kathey Marsden (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
>
> Kathey Marsden updated DERBY-700:
> ---------------------------------
>
> Component: Store
> Fix Version: (was: 10.1.3.0)
> 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)
>
> was:
>
>
> Sysinfo output.
>
> java -cp ./10.1.2.1/derby.jar org.apache.derby.tools.sysinfo
> ------------------ Java Information ------------------
> Java Version: 1.4.2_08
> Java Vendor: Sun Microsystems Inc.
> Java home: /usr/lib/SunJava2-1.4.2/jre
> Java classpath: ./10.1.2.1/derby.jar
> OS name: Linux
> OS architecture: i386
> OS version: 2.6.5-7.201-smp
> ...
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.4
> --------- Derby Information --------
> JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
> [/.../derby.jar] 10.1.2.1 - (330608)
> ------------------------------------------------------
> ----------------- Locale Information -----------------
> ------------------------------------------------------
>
>
>
>
>>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
>> Type: Bug
>> Components: Store
>> 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
>> Attachments: DualBootRepro.java
>>
>>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.
>
>
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
Kathey Marsden updated DERBY-700:
---------------------------------
Component: Store
Fix Version: (was: 10.1.3.0)
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)
was:
Sysinfo output.
java -cp ./10.1.2.1/derby.jar org.apache.derby.tools.sysinfo
------------------ Java Information ------------------
Java Version: 1.4.2_08
Java Vendor: Sun Microsystems Inc.
Java home: /usr/lib/SunJava2-1.4.2/jre
Java classpath: ./10.1.2.1/derby.jar
OS name: Linux
OS architecture: i386
OS version: 2.6.5-7.201-smp
...
java.specification.name: Java Platform API Specification
java.specification.version: 1.4
--------- Derby Information --------
JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
[/.../derby.jar] 10.1.2.1 - (330608)
------------------------------------------------------
----------------- Locale Information -----------------
------------------------------------------------------
> 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
> Type: Bug
> Components: Store
> 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
> Attachments: DualBootRepro.java
>
> 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
[jira] Assigned: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by "Suresh Thalamati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
Suresh Thalamati reassigned DERBY-700:
--------------------------------------
Assign To: (was: Suresh Thalamati)
> 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
> Type: Bug
> Components: Store
> 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
> Attachments: DualBootRepro.java, DualBootRepro2.zip
>
> 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