db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5283) Crash / process termination during SYSCS_DISABLE_LOG_ARCHIVE_MODE can leave service.properties broken
Date Wed, 31 Aug 2011 13:10:09 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094507#comment-13094507
] 

Kristian Waagan commented on DERBY-5283:
----------------------------------------

I think we can improve the situation here, and I have written a prototype patch that fixes
this.
However, before moving on to the code, I have a few questions.

Is it safe to assume that we can always undo the change to the properties file?
Undo would be to continue using the old properties file, and redo would be to start using
the new properties file.
I understand that some, if not most, of the properties are only set at database creation time.

There are two types of error conditions:
 a) The VM is killed while updating the service properties.
 b) Updating the service properties is aborted due to a problem (most likely file privileges
problem) - the VM stays up

In (a) recovery must happen on the next boot, whereas for (b) actions must be taken to correct
the situation immediately. Both of these cases would involve a set of file operations; verifying,
deleting, or renaming a file.
As a further improvement, I would suggest that we print an entry to derby.log when Derby automatically
recovers from a problem with the service.properties file.

When it comes to the content of the files on disk, are the following assumptions valid?
 1) Writing to streams from Java may produce incomplete files.
 2) Low level file operations invoked from Java, like delete and rename, will always result
in valid files on disk.
    Note that this does not imply that rename(old,new) is atomic, but, assuming new didn't
already exist, new will be a complete copy of old if it exists after the crash.

I started out with a rather complex solution for this (using checksums), but I think I'll
take the time to simplify it - we can add to it if required.

> Crash / process termination during SYSCS_DISABLE_LOG_ARCHIVE_MODE can leave service.properties
broken
> -----------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5283
>                 URL: https://issues.apache.org/jira/browse/DERBY-5283
>             Project: Derby
>          Issue Type: Bug
>          Components: Miscellaneous
>    Affects Versions: 10.6.1.0, 10.8.1.2
>         Environment: >sysinfo
> ------------------ Java Information ------------------
> Java Version:    1.6.0_26
> Java Vendor:     Sun Microsystems Inc.
> Java home:       C:\Program Files (x86)\Java\jre6
> Java classpath:  .;C:\Program Files (x86)\Java\jre6\lib\ext\QTJava.zip;C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\bin\../lib/derby.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\bin\../lib/derbynet.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\bin\../lib/derbyclient.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\bin\../lib/derbytools.jar
> OS name:         Windows 7
> OS architecture: x86
> OS version:      6.1
> Java user name:  bmason
> Java user home:  C:\Users\BMASON
> Java user dir:   C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\bin
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.6
> java.runtime.version: 1.6.0_26-b03
> --------- Derby Information --------
> JRE - JDBC: Java SE 6 - JDBC 4.0
> [C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\lib\derby.jar] 10.6.1.0 - (938214)
> [C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\lib\derbytools.jar] 10.6.1.0 - (938214)
> [C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\lib\derbynet.jar] 10.6.1.0 - (938214)
> [C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\lib\derbyclient.jar] 10.6.1.0 - (938214)
> ------------------------------------------------------
> ----------------- Locale Information -----------------
> Current Locale :  [English/New Zealand [en_NZ]]
> Found support for locale: [cs]
>          version: 10.6.1.0 - (938214)
> Found support for locale: [de_DE]
>          version: 10.6.1.0 - (938214)
> Found support for locale: [es]
>          version: 10.6.1.0 - (938214)
> Found support for locale: [fr]
>          version: 10.6.1.0 - (938214)
> Found support for locale: [hu]
>          version: 10.6.1.0 - (938214)
> Found support for locale: [it]
>          version: 10.6.1.0 - (938214)
> Found support for locale: [ja_JP]
>          version: 10.6.1.0 - (938214)
> Found support for locale: [ko_KR]
>          version: 10.6.1.0 - (938214)
> Found support for locale: [pl]
>          version: 10.6.1.0 - (938214)
> Found support for locale: [pt_BR]
>          version: 10.6.1.0 - (938214)
> Found support for locale: [ru]
>          version: 10.6.1.0 - (938214)
> Found support for locale: [zh_CN]
>          version: 10.6.1.0 - (938214)
> Found support for locale: [zh_TW]
>          version: 10.6.1.0 - (938214)
> ------------------------------------------------------
>            Reporter: Brett Mason
>
> If Derby is terminated while SYSCS_DISABLE_LOG_ARCHIVE_MODE is being called service.properties
can be left in a broken state.
> Depending on timing either of the two cases can happen:
> Case 1:
> "ERROR XBM0S: Unable to rename file 'C:\PATH_TO_DB\service.properties' to 'C:\PATH_TO_DB\service.propertiesold'
" is thrown when next trying to call
> SYSCS_DISABLE_LOG_ARCHIVE_MODE(1). Both "service.properties" and "service.propertiesold"
are present in the database directory. Removing "service.propertiesold" corrects the problem.
> Case 2:
> "SQLException: Database 'C:\PATH_TO_DB' not found" is thrown when booting the database.
The file service.properties does not exist in the database directory but service.propertiesold
does exist. Renaming the file back to "service.properties" corrects the problem.
> As mentioned above both cases have workarounds but they require manual intervention which
is a problem for applications installed to a customer site. It would be great if a more reliable
method to update the file could be found.
> The following sample code will reproduce the issue fairly reliably by terminating the
java process:
> import java.sql.*;
> import org.apache.derby.jdbc.*;
> public class DerbyLogArchiveModeTest {
>     
>     public static void main(String[] args) {
>         final EmbeddedDataSource ds = new EmbeddedDataSource();
>         ds.setDatabaseName("derbyTest");
>         ds.setCreateDatabase("create");
>         try {
>             final Connection conn = ds.getConnection();
>             try {
>                 final Statement stmt = conn.createStatement();
>                 try {
>                     while (true) {
>                         stmt.execute("call SYSCS_UTIL.SYSCS_DISABLE_LOG_ARCHIVE_MODE(1)");
>                     }
>                 } finally {
>                     stmt.close();
>                 }
>             } finally {
>                 conn.close();
>             }
>         } catch (SQLException e) {
>             e.printStackTrace();
>         }
>     }
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message