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