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) <derby-dev@db.apache.org> 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

Reply via email to