[
https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509170
]
Daniel John Debrunner commented on DERBY-700:
---------------------------------------------
Expanding the synchronization "because it works" concerns me greatly as an
engineering approach to addressing a synchronization issue.
The purpose of the synchronization was intended to protect a small window while
a unique identifier was being written into a file (exFileLock in
privGetJBMSLockOnDB) used for lock control.
Expanding this synchronization is now also protecting the writing of a
*different* file (fileLock in privGetJBMSLockOnDB), but why is that needed?
Especially when the system has to handle multiple jvm's writing to that same
file, when object synchronization doesn't help.
It maybe that the current locking across doesn't really work and there are
windows where multiple jvms booting the same database at the same time would
succeed when they should fail. E.g. the locking works correctly when two jvms
boot the same database one after the other (ie the second would fail) but not
when they concurrently boot the same db. Maybe your test is exposing that and
so the synchronization is required, but then it doesn't address the cross jvm
issue.
The locking of database boot is already complicated and adding the new
(required) mechanism for cross-class loader complicates it further.
It would be good to have a clear description of how the various schemes work
and interact with each other. WIth that, one could then more easily determine
what synchronization is required *and why*.
> 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_06_19_2007, 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, 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.
