db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux
Date Tue, 01 Aug 2006 17:35:15 GMT
I haven't looked at this yet, just wanted to say that when I proposed a 
single system property (vs. one system prop per database), there was
opposition in the community.

Some things to think about:
o can the same database ever have "2" names - ie. if the location is
   /x/y/wombat and one person accesses as system=/x and db=y/wombat
and another system= /x/y and db=wombat.

o what about when a derby instance fails, like a null pointer or some
   othe bug.  Will the system prop be left around?

o how do you handle synchronization of 2 connects at basically the same
   time?

V.Narayanan (JIRA) wrote:
>      [ http://issues.apache.org/jira/browse/DERBY-700?page=all ]
> 
> V.Narayanan updated DERBY-700:
> ------------------------------
> 
>     Attachment: DERBY-700.diff
>                 DERBY-700.stat
> 
> Hi,
> 
> We could solve this problem by setting a System property before booting a database and
checking for the property during subsequent boots. When the database is shutdown we set the
property to false. For example when we boot a database named mydb then we set the property
derby.dblock.mydb = true. Now during subsequent boots we could check for this system variable
and if it is set to true throw an exception. During the shutdown of the database we set this
variable to false. I tried an attempt along this line in the attached patch. 
> 
> I HAVE NOT run the patch with security manager enabled. The sample repro attached with
this issue passes with this fix. 
> 
> Pls note that the patch is not for a commit but is just to represent what I have in mind
as a solution, in the form of code. 
> 
> thanx
> 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, DualBootRepro.java, DualBootRepro2.zip
>>
>>
>>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.
> 
> 


Mime
View raw message