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