[ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
V.Narayanan updated DERBY-700:
------------------------------
Attachment: DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff
DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat
DualBootRepro_mutltithreaded.tar.bz2
Hi,
THESE ATTACHMENTS ARE JUST AN ATTEMPT IN THE SIMULATION OF THE COMMENTS ABOVE.
THEY ARE NOT FOR A COMMIT. PLS FOLLOW BELOW COMMENTS FOR DETAILS.
Thanx for going through the patch and giving comments
>Using system properties will require that every user running with the
>security
manager grant a new permission in their policy file to allow setting these
system
properties.
I Agree, My apologies for not having gone through the earlier thread on
System
Properties
> One issue with system properties is that how do atomically set and get the
property, I think that is needed to perform locking? In your current patch,
there is a
window between where you get and set the property where another thread in
a
anoter class loader could come in and "lock" the database, resulting in two
active
derby instances connecting to the same database.
Again a very valid point. I wanted to try to simulate this. So converted the
whole
repro into a crude multi -threaded application. But found found it
difficult to
simulate it on my machine since one of the threads always managed to set
this
property before the other. So modified my fix by creating a sort of sync
point after
the getProperties. Just to show that two seperate threads could actually
reach
there.
This could actually occur without this modification
1) When one of the threads gets preempted after doing a getProperties and
then
the other does a getProperties. And then they proceed to completion.
Also this might just be one of the cases when this could have occurred.
> I also don't understand why on getting the system property you are catching
NullPointerException and IllegalArgumentException, how would these be
thrown
by System.getProperty()?
NullPointerException - System.getProperty(null);
IllegalArgumentException - System.getProperty("");
I found it interesting to simulate the condition where the above fix might
fail.
Thought I could share the same with the community. So attaching the relevant
files
I used for generating this condition.
thanx once again for the patient comments
Narayanan
> Derby does not prevent dual boot of database from different classloaders on
> Linux
> ---------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: http://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
> Assigned To: V.Narayanan
> Priority: Critical
> Fix For: 10.2.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat,
> DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff,
> DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat, DualBootRepro.java,
> DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
