db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V.Narayanan (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
Date Wed, 02 Aug 2006 06:33:14 GMT
     [ 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 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.
-
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

        

Mime
View raw message