db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Thalamati <suresh.thalam...@gmail.com>
Subject Re: [jira] Commented: (DERBY-239) Need a online backup feature that does not block update operations when online backup is in progress.
Date Wed, 11 Jan 2006 00:51:33 GMT
Øystein Grøvlen wrote:
> Suresh,
> Thanks for considering my suggestions.  A few responses below.
> --
> Øystein

>     >> - Is checkBackupTransactionIsIdle() strictly necessary here?  This
>     >> seems like an operation where failures could be handle at
>     >> statement level.
>     >> 
>     ST> No.  Idle check  was  necessary  for issuing  implicit  commit to  be
>     ST> consistent with other backup calls.
> Is this really a backup call?

Not a real backup call, but it related to the backup functionality and
disabling the log archive mode operation can not be rolled back, that
was the reason behind doing the implicit commit for this call also. I
will be  removing the IDLE check and implicit commit in this case also
along with other backup calls.

>     >> java/engine/org/apache/derby/iapi/store/raw/xact/TransactionFactory.java
>     >> * stopBackupBlockingOperations()
>     >> - Name indicates that backup blocking operations are stopped, but
>     >> javadoc says that only new ones are blocked.  I think the name
>     >> is misleading.
>     >> - Javadoc should be revisited for typos.
>     ST> I can change them too :
>     ST> blockBackupBlockingOperations()
>     ST> unblockBackupBlockingOoperation()
>     ST> Any suggestions ?
> I guess you mean unblockBackupBlockingOperations().  Names are OK.  It
> requires a bit of syntactic and semantic analysis to be grasp the
> meaning of 'blockBackupBlocking', but I do not have a better
> suggestion.
>     >> java/engine/org/apache/derby/impl/store/raw/xact/Xact.java
>     >> * setBackupBlockingState()/setUnblockBackupState()
>     >> - Names should be symmetric.  (e.g., blockBackup/unblockBackup)
>     >> - Why do you have to wait for commit to unblock?  Would it not be
>     >> sufficient to have completed the unlogged operations before
>     >> backup is started?
>     ST> May be backup can be allowed once the unlogged operation is complete,
>     ST> I  have not  looked  in-depth  to allow  immediately  after the  unlog
>     ST> operations is complete, one case that I thought likely to have
>     ST> problem is JAR file removal on post commit conflicting with backup
>     ST> jar copy operation.
>     ST> For now, I think enforcing the COMMIT restriction is ok.
> Enforcing the commit restriction is the root of the discussions we
> have had on idle transactions and automatic commit.  If it is
> necessary, things would be more straight-forward.  
> I would think whether the COMMIT restriction is necessary or not,
> depends on whether one at restore will be able to roll back these
> operations.  I guess an index is ok to back up after it has been
> created since it should be possible to roll back the creation by
> dropping the index should the transaction never commit.

Commit/Rollback is not a necessary condition, technically backup needs
to be blocked only for the duration of a unlogged operation.  It is
just simpler to test and implement online backup if backup is
unblocked on commit/rollback in these cases.  To unblock immediately
after the unlogged operation, I would need to go through all the code
for unlogged operation and make sure unblock of backup is done at the
right place and testing becomes more tricky.

I believe blocking the backup until unlogged operations are committed
is acceptable for now, because typically users will issue a
commit/rollback after the unlogged operations are complete. User
application is required to do  anything special in this case, backup
will just block for more time than ideally required. If some one finds
this is not acceptable, online backup can be enhanced to block only
for the duration of the unlogged operation at a later point of time.


View raw message