approach #2 seems more "online", if it doesn't cause other problems it
seems better. In reality I don't think most users will see any
difference as it seems wierd to on purpose be doing other things in
a transaction and then execute a backup. Documentation should be clear
that Derby cannot back out a backup.
Suresh Thalamati wrote:
Thanks for taking time to review. My comments are in-line for some
of the questions, I will respond to the other questions in another e-mail.
From you comments, one issue that we are uable to come to conclusion,
is what to do if a backup call is issued in a transaction that already
has a pending unlogged operations.
1) Current approach:
a) permit backup call only in a non-idle transaction.
b) issue a implicit commit/rollback after the backup call is done.
2) Other approch is :
a) prevent backup calls only when a transaction already has executed
unlogged operations.
b) Don't issue implicit commit/rollback after the backup
I am ok with either of these approaches. I would like to know if anyone
prefers one approach over the other.
Øystein Grøvlen (JIRA) wrote:
[
http://issues.apache.org/jira/browse/DERBY-239?page=comments#action_12361535
]
Øystein Grøvlen commented on DERBY-239:
---------------------------------------
I have reviewed the latest patches (3 through6). (A bit late I must
admit). Here are my comments:
* SYSCS_ONLINE_BACKUP_DATABASE()
- Since both backup procedures are ONLINE, it is a bit misleading
to use this word to distinguish between the two backup
procedures. I guess the main reason for choosing a new name is
the extra parameter. In that case, I think it would be better
to name the new procedure, SYSCS_BACKUP_DATABASE_NOWAIT and
leave out the parameter.
- The javadoc does not say what will happen if wait is 0. Will one
get an exception if there is unlogged operations?
I also think SYSCS_BACKUP_DATABASE_NOWAIT makes more sense, will
change the the procedure names with ONLINE to NO_WAIT, if no one else
has any objections.
SYSCS_BACKUP_DATABASE_NOWAIT
SYSCS_ONLINE_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE_NO_WAIT
* backupDatabase()
- Is this the right layer for checking that the transaction is
idle and for doing rollback/commit the transaction? Since this
is a requirement for the logic at lower layers to work
correctly, not something that is done because it is the
desirable behavior of the system procedure, I feel that this
should be done at a lower layer.
I think so, because it is better to commit/rollback at the jdbc layer
level than in rawstore, becuase if we add anything in language area for
backup , it will surprise us.
in non-idle transaction error case backup should not commit/rollback,
that is why I pushed the check to jdbc level and also checking for
transaction is IDLE is already exposed to JDBC for some other code.
Other approach was to make rawstore throw the error and cacth the error
in the jdbc layer and decide to issue commit/rollback.
I generally don't like catching exception and then deciding what to
based on the SQLState, so I decided to check for the transaction idle
state in SystemProcedures.java
- I know when we discussed this isssue earlier, I agreed that
checking that the transaction is idle was a good solution.
However, thinking a bit more about this, I think it would be
better to fail the transaction when unlogged operations have
been performed by the same transaction. That would limit it to
those who actually need to be affected, and it would
significantly reduce the probability of someone ever
experiencing this problem.
It is very rare that some user stating a backup in a non-idle
transaction. If you think there is a possibilty of users executing
backup in non-idle transactions, then we can change the backup to check
only for non-logged cases as us suggested. But if
we follow this approach then we can commit/rollback after the backup.
- I am not very fond of automatic commits like this.
I think it was decided in earlier e-mails that backups need not be
transactional. So it is good to issue commit becuase we are sure
transaction is in idle state when backup was started.
If this is
necessary, I think it would be better to require that backup is
performed in autocommit mode. Then the implications would be
more evident to the users and not catch someone by surprise.
I think forcing for the backup to work only on autocommit is likely to
break existing applications that are doing backup in autocommit=false mode.
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: obtest_customer.jar, onlinebackup.html,
onlinebackup1.html, onlinebackup_1.diff, onlinebackup_2.diff,
onlinebackup_3.diff, onlinebackup_4.diff, onlinebackup_5.diff,
onlinebackup_6.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.
