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.
