[
https://issues.apache.org/jira/browse/KUDU-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17219423#comment-17219423
]
ASF subversion and git services commented on KUDU-2612:
-------------------------------------------------------
Commit e64eb7c7ceceec76aeb5cceac9dc42cc0e78f1ec in kudu's branch
refs/heads/master from Alexey Serbin
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=e64eb7c ]
KUDU-2612: C++ client sets txn_id in WriteRequestPB
This patch introduces an optional 'txn_id' field into WriteRequestPB
protobuf message and changes Kudu C++ client to populate it for
all requests sent out from a transactional KuduSession. In addition,
this patch contains unit-level test to verify that KuduSession and
Batcher have their txn_id_ fields set correspondingly. It's assumed
that follow-up changelists will add more comprehensive end-to-end
coverage once transactional API for Kudu client is introduced and
tablet servers process the WriteRequestPB:txn_id field as prescribed
by the design document [1].
A follow-up changelist will introduce corresponding client API changes
for transaction-related operations, and with those it will be possible
to begin, commit, and rollback a transaction. However, I think it's
important to highlight a few assumptions that Andrew and I discussed
offline: this patch assumes that a single KuduSession isn't allowed
to have a mix of transactional and non-transactional write operations.
Also, all write operations handled by a KuduSession instance can be
attributed only to a single (the same) transaction. In other words,
it's assumed that a separate KuduSession instances should be created
to handle operations pertaining to different transactions. This
restriction doesn't seem to be too harsh, but it helps to avoid a
complicated dance in handling already accumulated write operation in
KuduClient. Otherwise, it would be necessary to flush buffered
operations if switching from non-transactional writes to transactional
ones and back. If it turns out that the functionality of mixing
transactional and non-transactional write operations is necessary,
this restriction can be removed: it's feasible to add transaction
control operations into KuduSession in future (i.e.
{Begin,Commit,Abort}Transaction() methods), but it will entail adding
more complexity into already convoluted client-side code of handling
buffered write operations.
For now, I decided not to expose txn_id via the public client API.
Also, I specifically avoided exposing txn_id via KuduWriteOperation as
well, keeping it a private member of internal classes KuduSession::Data
and Batcher.
[1] https://s.apache.org/kudu-multi-row-transaction-design
Change-Id: Ib60cb0ea8066e2c6417ebe4b2a24aff3512b44f1
Reviewed-on: http://gerrit.cloudera.org:8080/16625
Reviewed-by: Andrew Wong <aw...@cloudera.com>
Tested-by: Kudu Jenkins
Reviewed-by: Hao Hao <hao....@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)
