[
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 [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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
