[
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
