I like option 1, make sure it is well documented. I actually lean
toward even stronger, have the command commit the current transaction
before and after the backup.
Suresh Thalamati (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-239?page=comments#action_12356240 ]
Suresh Thalamati commented on DERBY-239:
----------------------------------------
What to do if backup is started in a transaction that already has unlogged
operations executed?
In previous discussions about online backup, it was concluded that existing
backup procedures calls will WAIT for the transaction with unlogged
operations to commit before proceeding with the backup. One issue that was
missing from the discussion was, what to do if user starts a backup
in the same transaction that has unlogged operations executed before the backup call.
WAIT will not be an acceptable option here, because backup call will wait forever.
I can think of two ways this issue can be addressed:
1) Add a restriction that backup procedures can only be called in a brand
NEW transaction. And also implicitly commit the backup transaction at the end of the
backup. Commit is not required as such to solve this problem, but it would
be cleaner because backup itself is not a rollback-able operation.
2) Make backup procedures fail, if transaction that it is started in
contains unlogged operations.
I am inclined towards implementing the first option. Any comments/suggestion
will be appreciated.
Thanks
-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.
