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 Wed, 13 Jun 2007 23:03:26 GMT

    [ 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:
>         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:
>         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, you can change the location by changing
the DERBY_LIB_DIR variable.
> On Linux the output is:
> $java -cp . DualBootRepro
> Loading derby from file:
> 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:
> 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.

View raw message