[
https://issues.apache.org/jira/browse/KUDU-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17157206#comment-17157206
]
ASF subversion and git services commented on KUDU-2612:
-------------------------------------------------------
Commit f08d524ac73dbbac6962a8fa857eaaa5701a6809 in kudu's branch
refs/heads/master from Andrew Wong
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=f08d524 ]
KUDU-2612 p3: tserver mechanism to create txn status tablets
This introduces the concept of a table type in tablets. This is used in
the context of creating transaction status table partitions; if a tablet
replica is created as a partition of a transaction status table, the
underlying replica will initialize some state to manage and coordinate
transactions -- namely, a TxnStatusManager.
For the sake of decoupling submodules, to get a TabletReplica to
initialize a TxnStatusManager, this patch introduces the
tablet::TxnCoordinator and tablet::TxnCoordinatorFactory interfaces that
TxnStatusManager and the new TxnStatusManagerFactory implement
respectively. The TxnStatusManagerFactory can be created by members of
the tserver and passed to TabletReplicas upon initialization -- this
layer of indirection will allow us to use tserver-wide state (e.g. in
the future, a system client) without muddying the tablet subdirectory
too much.
This approach lies in contrast to the approach used for the
CatalogManager, in which the master server owns a CatalogManager that
owns the underlying SysCatalogTable and TabletReplica. I went down this
route because unlike the CatalogManager replicas, I expect the replicas
of TxnStatusTablets to be dynamically moved around, and so it behooves
us to reuse as much of the existing tserver replica management code as
possible. To that end, the ownership relationship between management
state and underyling tablet replica is flipped, with the TabletReplica
owning the TxnStatusManager.
The plumbing only extends through the tablet servers -- the ability to
create transaction status tables and define partitioning is not yet
plumbed into the master. Additionally, there is still currently no means
to restrict calls to the TxnStatusManagers whose underlying replicas are
running leaders -- that will also come in later patches.
Change-Id: Ib429f055e12944fa930f3e95ec4f2504466d3d02
Reviewed-on: http://gerrit.cloudera.org:8080/16116
Tested-by: Kudu Jenkins
Reviewed-by: Alexey Serbin <[email protected]>
> 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)
