Øystein Grøvlen wrote:
Suresh,
Thanks for considering my suggestions. A few responses below.
--
Øystein
>> * SYSCS_DISABLE_LOG_ARCHIVE_MODE()
>> - 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.
Thanks
-suresh
