db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1838) Derby allows dual boot which can cause corruption of databases with JVM's lower than 1.4.2 on non-windows systems
Date Tue, 12 Sep 2006 08:49:23 GMT
    [ 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

        

Mime
View raw message