[ http://issues.apache.org/jira/browse/DERBY-298?page=comments#action_12362691 ]
Daniel John Debrunner commented on DERBY-298: --------------------------------------------- This patch added two new tests, RecoveryAfterBackup and RecoveryAfterBackupSetup, both of which are being run without a SecurityManager due to the noSecurityManager=true in their _app.properties files. Why are these tests excluded from running with a SecurityManager? It should be rare that a test is to not to be run with a SecurityManager, if such a need arises the noSecurityManager=true must be commented to indicate why this is the case. The default for any new tests in the existing harness should be to run with the SecurityManager. There are a handful of tests that have noSecurityManager=true with no comment or a comment that says needs investigating, I'm working on all of these since they are exisiting tests, but it's not my itch to clean up new tests. > rollforward will not work correctly if the system happens to crash > immediately after rollforward backup. > --------------------------------------------------------------------------------------------------------- > > Key: DERBY-298 > URL: http://issues.apache.org/jira/browse/DERBY-298 > Project: Derby > Type: Bug > Components: Store > Versions: 10.0.2.1 > Reporter: Suresh Thalamati > Assignee: Øystein Grøvlen > Priority: Minor > Fix For: 10.1.3.0, 10.2.0.0 > Attachments: derby-298.diff, derby-298a.diff, derby-298b.diff > > If the system crashes after a rollforward backup; last log file > is empty(say log2.dat). On next crash-recovery system ignores the empty log > file and starts writing to the previous log(say log1.dat), > even thought there was successfule log file switch before the crash. > The reason I belive it is done this way to avoid special > handling of crashes during the log switch process. > Problem is on rollfroward restore from a backup log1.dat will get > overwritten > from the copy in the backup, so any transaction that got added to log1.dat > after the backup was taken will be lost. > > One possible solution that comes to my mind to solve this problem is > 1) check if an empty a log file exist after a redo crash-recovery , if > the log archive mode is enabled. > 2) If it exists , delete and do log file switch again > > Repro: > connect 'jdbc:derby:wombat;create=true'; > create table t1(a int ) ; > insert into t1 values(1) ; > insert into t1 values(2) ; > call SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE( > 'extinout/mybackup', 0); > --crash (NO LOG RECORDS WENT IN AFTER THE BACKUP). > connect 'jdbc:derby:wombat'; > insert into t1 select a*2 from t1 ; > insert into t1 select a*2 from t1 ; > insert into t1 select a*2 from t1 ; > insert into t1 select a*2 from t1 ; > insert into t1 select a*2 from t1 ; > insert into t1 select a*2 from t1 ; > insert into t1 select a*2 from t1 ; > select count(*) from t1 ; > --exit from jvm and restore from backup > connect > 'jdbc:derby:wombat;rollForwardRecoveryFrom=extinout/mybackup/wombat'; > select count(*) from t1 ; -- THIS WILL GIVE INCORRECT VALUES -- 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
