I agree that option 1 is to be preferrable. I do not think there is
any need for transactional behavior for backup.
--
Øystein
>>>>> "ST(" == Suresh Thalamati (JIRA) <[email protected]> writes:
ST(> [
http://issues.apache.org/jira/browse/DERBY-239?page=comments#action_12356240 ]
ST(> Suresh Thalamati commented on DERBY-239:
ST(> ----------------------------------------
ST(> What to do if backup is started in a transaction that already has
unlogged operations executed?
ST(> In previous discussions about online backup, it was concluded that
existing
ST(> backup procedures calls will WAIT for the transaction with unlogged
ST(> operations to commit before proceeding with the backup. One issue that
was
ST(> missing from the discussion was, what to do if user starts a backup
ST(> in the same transaction that has unlogged operations executed before
the backup call.
ST(> WAIT will not be an acceptable option here, because backup call will
wait forever.
ST(> I can think of two ways this issue can be addressed:
ST(> 1) Add a restriction that backup procedures can only be called in a
brand
ST(> NEW transaction. And also implicitly commit the backup transaction
at the end of the
ST(> backup. Commit is not required as such to solve this problem, but
it would
ST(> be cleaner because backup itself is not a rollback-able operation.
ST(> 2) Make backup procedures fail, if transaction that it is started in
ST(> contains unlogged operations.
ST(> I am inclined towards implementing the first option. Any
comments/suggestion
ST(> will be appreciated.
ST(> Thanks
ST(> -suresht
>> Need a online backup feature that does not block update operations
when online backup is in progress.
>>
--------------------------------------------------------------------------------------------------------
>>
>> Key: DERBY-239
>> URL: http://issues.apache.org/jira/browse/DERBY-239
>> Project: Derby
>> Type: New Feature
>> Components: Store
>> Versions: 10.1.1.0
>> Reporter: Suresh Thalamati
>> Assignee: Suresh Thalamati
>> Attachments: onlinebackup.html, onlinebackup_1.diff
>>
>> Currently Derby allows users to perfoms online backups using
SYSCS_UTIL.SYSCS_BACKUP_DATABASE() procedure, but while the backup is in
progress, update operations are temporarily blocked, but read operations can
still proceed.
>> Blocking update operations can be real issue specifically in client
server environments, because user requests will be blocked for a long time if a
>> backup is in the progress on the server.
ST(> --
ST(> This message is automatically generated by JIRA.
ST(> -
ST(> If you think it was sent incorrectly contact one of the administrators:
ST(> http://issues.apache.org/jira/secure/Administrators.jspa
ST(> -
ST(> For more information on JIRA, see:
ST(> http://www.atlassian.com/software/jira
--
Øystein
