[
http://issues.apache.org/jira/browse/DERBY-1838?page=comments#action_12434090 ]
John H. Embretsen commented on DERBY-1838:
------------------------------------------
The Derby documentation specifies Java version 1.4 as the version with which a
dual boot may be prevented automatically. Kathey reported version 1.4.2 as the
critical one. I tried dual booting a database via IJ (trunk) using Sun's JDK
1.4.1, and I got ERROR XJ040 and ERROR XSDB6, as described on the doc page
referenced by Suresh. So it seems that preventing dual boots also works with
1.4.1, and I assume that the documentation is accurate (the OS I tested on was
Solaris 10 x86).
With JDK 1.3.1 I am able to dual boot a database, and I get a WARNING similar
to the one described on the above mentioned doc page.
I also tried using the derby.database.forceDatabaseLock property with JDK
1.3.1, and it works as described in the docs [1], i.e. it prevents dual booting
of the database. The error message I get in IJ could be improved, though. For
example, it refers to the wrong property name, db2j.database.forceDatabaseLock
instead of derby.database.forceDatabaseLock, and {1} and {2} are not replaced
with real values:
ij> connect 'jdbc:derby:dualBootDB';
ERROR XJ040: Failed to start database 'dualBootDB', see the next exception for
details.
ERROR XSDB8: WARNING: Derby (instance [Ljava.lang.Object;@617189) is attempting
to boot the database {1} even though Derby (instance {2}) may still be active.
Only one instance of Derby should boot a database at a time. Severe and
non-recoverable corruption can result if 2 instances of Derby boot on the same
database at the same time. The db2j.database.forceDatabaseLock=true property
has been set, so the database will not boot until the db.lck is no longer
present. Normally this file is removed when the first instance of Derby to
boot on the database exits, but it may be left behind in some shutdowns. It
will be necessary to remove the file by hand in that case. It is important to
verify that no other VM is accessing the database before deleting the db.lck
file by hand.
[1] http://db.apache.org/derby/docs/dev/tuning/rtunproper81405.html
> Derby allows dual boot which can cause corruption of databases with JVM's
> lower than 1.4.2 on non-windows systems
> ------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1838
> URL: http://issues.apache.org/jira/browse/DERBY-1838
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.1.0,
> 10.1.2.1, 10.1.3.0, 10.3.0.0, 10.1.4.0, 10.1.3.1, 10.1.3.2, 10.2.2.0
> Reporter: Kathey Marsden
> Priority: Critical
>
> On non-windows systems accidental access of a database from two JVM's is not
> prevented on JVM's lower than 1.4.2. The issue can be triggered by a
> common user error, for example accessing a database from two ij sessions.
> This can cause unrecoverable corruption. It is critical that users upgrade
> to 1.4.2 if there is a possibility that a user might access Derby in this way.
> There was no known way to fix this issue until 1.4.2, so it is not likely
> that it can be resolved within Derby. Upgrade of the JVM is the only known
> solution now.
> Note: Even with 1.4.2 the dual boot issue exists in certain scenarios which
> are not well documented. DERBY-700 has been filed and hopefully other fatal
> usage cases that can lead to dual boot can be isolated and resolved.
--
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
