db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
Date Fri, 15 Jun 2007 17:55:27 GMT

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


Mime
View raw message