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

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

Commit 45ca93f0ef90a8524d0fcd9c3e56e10d5328ca24 in kudu's branch 
refs/heads/master from Alexey Serbin
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=45ca93f ]

KUDU-2612 automatically flush sessions on txn commit

With this patch, all transactional sessions created off a transction
handle are automatically flushed upon calling Commit() on the handle.

As for the KuduTransaction::StartCommit() method, it's now necessary
to flush all the transactional sessions created off the transaction
handle before calling the method, otherwise Status::IllegalState()
would be returned.

As Andrew and I discussed offline, it might be an option to return an
error from KuduSession::Apply() for a transactional session whose
transaction has already started committing.  However, after looking at
this closer, I realized that it would require either an atomic or an
extra synchronization primitive, bringing more complexity into the hot
path of applying write operations in the context of a session.  So,
I opted not to perform the consistency check as a part of the
KuduSession::Apply() method, rather relying on the logic of
KuduSession::Flush() and KuduSession::FlushAsync() methods instead.

Another design detail worth pointing at is that a KuduTransaction handle
keeps shared, not weak pointers to transaction sessions originated off
the handle (I did several back-and-forth iterations on this, though).
Even if using shared_ptr, not weak_ptr, no circular dependencies are
introduced since a transactional session doesn't keep a reference
to the corresponding transactional handle.  The shared_ptr-based
approach looks better than one with weak_ptr because
  (1) It might prevent a data loss due to a mistake in an application
      code, and it takes time to find and fix those.
  (2) It looks more portable and consistent if thinking about similar
      functionality to implement in the Java client.

This patch also contains several test scenarios for the newly introduced
functionality.

Change-Id: I2480129a99fb19d16868e14f9b9e33c83e3d8e7f
Reviewed-on: http://gerrit.cloudera.org:8080/17431
Tested-by: Alexey Serbin <aser...@cloudera.com>
Reviewed-by: Andrew Wong <aw...@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