[ 
https://issues.apache.org/jira/browse/KUDU-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17279428#comment-17279428
 ] 

ASF subversion and git services commented on KUDU-2612:
-------------------------------------------------------

Commit b9a8f2e633af891b6e2b268a71e18a8e7e1ff34d in kudu's branch 
refs/heads/master from Andrew Wong
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=b9a8f2e ]

KUDU-2612: background task to commit transaction

This patch introduces background tasks that get run when
KuduTransaction::Commit() is called. The typical workflow is as follows:
1. Commit() is called, resulting in a BeginCommitTransaction() call on
   the TxnStatusManager.
2. An update is made to the transaction status table, marking the
   transaction's state as COMMIT_IN_PROGRESS.
3. The commit tasks are initiated -- BEGIN_COMMIT ops are sent
   asynchronously to every participant of the transaction.
4. Once all responses are received from the participants, a commit
   timestamp is determined, and FINALIZE_COMMIT ops are sent
   asynchronously to every participant.
5. Once all responses are received from the participants, an update is
   made to the transaction status table, marking the transaction's state
   as COMMITTED.

There are some nuances here around error handling. Namely, what do we do
if there are errors in sending the above requests? Well, it depends on
the error. Transient errors (i.e. timeouts) are simply retried. More
permanent errors need a bit more thought though:
- If a participant has been deleted, what do we do? This patch makes a
  best effort attempt to abort the transaction if so.
- Any other kinds of errors (e.g. illegal state errors from a
  participant) aren't expected in normal operation of a cluster. For
  this, we stop the commit task and log a warning. Hopefully an operator
  can intervene.

Some follow-ups to expect:
- This isn't as robust to failures as an approach that writes an
  intermediate state to the TxnStatusManager in between steps 3 and 4. A
  follow-up patch will implement that.
- A separate patch will implement aborting transactions.
- I disabled the background tasks in some tests that assume state
  changes are entirely controlled by clients. A follow-up change will
  address these to account for the state changes more organically.

Change-Id: Ie2258dded3ab3d527cb5d0abdc7d5e7deb4da15e
Reviewed-on: http://gerrit.cloudera.org:8080/16952
Tested-by: Kudu Jenkins
Reviewed-by: Alexey Serbin <aser...@cloudera.com>


> Implement multi-row transactions
> --------------------------------
>
>                 Key: KUDU-2612
>                 URL: https://issues.apache.org/jira/browse/KUDU-2612
>             Project: Kudu
>          Issue Type: Task
>            Reporter: Mike Percy
>            Priority: Major
>              Labels: roadmap-candidate
>
> Tracking Jira to implement multi-row / multi-table transactions in Kudu.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to