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 [EMAIL PROTECTED]
FAIL: Booted database in 2nd loader [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
PASS: Expected exception for dualboot:Another instance of Derby may have
already booted the database D:\marsden\repro\dualboot\mydb.
