Thanks Øystein. I did not realize, my reply was not going derby-dev.
-suresh
Øystein Grøvlen wrote:
Suresh,
I guess you got hit by the derby-dev reply-to problem. I guess you
would want to send your email there.
I agree with what you say here. I think blocking on backup when
loading jar files are OK. I am currently reviewing your code, and I
have already seen that you handle the log copying correctly there.
--
Øystein
"ST" == Suresh Thalamati <[EMAIL PROTECTED]> writes:
ST> Øystein Grøvlen wrote:
>>>>>>> "ST(" == Suresh Thalamati (JIRA) <[email protected]> writes:
>>
ST> ..<snip>
>> ST(> Attachment: onlinebackup.html
>> ST(> functional/design spec based on the input I got on the
>> derby-dev list. Very good spec that seems to cover the necessary
>> issues. I have a few
>> minor comments:
ST> Thanks for reviewing the spec.
>> - Log files: I would think you may in some cases have to
>> copy
>> log files from before the backup checkpoint in order to be
>> able to roll-back transactions that started before the
>> backup. (Or am I missing something).
ST> No, you are right. Log files before the backup checkpoint are needed
ST> for rollbacks. I will edit the spec, the correct statement should be:
ST> "All the transaction log files starting from the log file that
ST> contains Undo Low Water Mark of the backup checkpoint to the log file
ST> that is active at the end of the backup are copied into the backup. "
>> - Jar files: What if a jar file is stored in the database
>> during backup? Will this be allowed? If yes, how is it
>> made sure that this is copied into the backup.
ST> Good point. I think jar file actions have to be aware of the parallel
ST> backup activity and vice versa, otherwise database in the backup can
ST> possibly get into a consistent state. Because the catalog updates are
ST> logged, but not the jar files it self, so it is possible that backup
ST> database catalog(sys.sysfiles) will have a reference to a file that
ST> does not exist in the backup database.
ST> I think this problem can be solved by doing the following:
ST> 1) make backup wait for all jar file activity in progress to complete,
ST> before copying the jar files from the database to the backup.
ST> 2) make any new jar file activity after the backup of jar files starts
ST> to wait/fail.
ST> I believe jar file action is not very common, so blocking them may not
ST> be that bad for the users. Window of blocking can be reduced by
ST> copying the jar files after the data segment. If some one thinks
ST> making jar file requests fail while backup is running is better
ST> approach, I am ok with it.
>> - Testing: I think it is important to test that this handles
>> rollback of transactions correctly. There should be a test
>> that runs with a higher than normal frequency for
>> transaction rollbacks. - Generally, tests should make
>> sure that ACID properties are
>> guaranteed after a restore.
>>
ST> Agree with you. I will add tests to cover the above scenarios.
ST> Thanks
ST> -suresht
