[ 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)