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 [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.
