You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "V.Narayanan (JIRA)" <de...@db.apache.org> on 2006/08/01 14:47:15 UTC
[jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
[ 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.
--
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
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Posted by Narayanan <V....@Sun.COM>.
Hi,
Thanx a ton for the issues you have highlighted. I am sorry to have
missed on the earlier chain of emails regarding proposal of single
system property. I was just proposing the system property as a possible
solution and I see the arguments against it as valid. My attempt at
creating a rather crude simulation of the problem that can occur because
of synchronization is attached to derby-700.
thanx once again,
Narayanan
Mike Matrigali wrote:
> 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.
>>
>>
>
Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot
of database from different classloaders on Linux
Posted by Mike Matrigali <mi...@sbcglobal.net>.
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.
>
>