[Tarantool-patches] [PATCH 8/8] replication: write and read CONFIRM entries
Vladislav Shpilevoy
v.shpilevoy at tarantool.org
Thu Jun 11 16:04:06 MSK 2020
>>> diff --git a/src/box/txn.c b/src/box/txn.c
>>> index a65100b31..3b331fecc 100644
>>> --- a/src/box/txn.c
>>> +++ b/src/box/txn.c> @@ -510,13 +518,6 @@ txn_journal_entry_new(struct txn *txn)
>>> struct xrow_header **remote_row = req->rows;
>>> struct xrow_header **local_row = req->rows + txn->n_applier_rows;
>>> bool is_sync = false;
>>> - /*
>>> - * Only local transactions, originated from the master,
>>> - * can enter 'waiting for acks' state. It means, only
>>> - * author of the transaction can collect acks. Replicas
>>> - * consider it a normal async transaction so far.
>>> - */
>>> - bool is_local = true;
>> I squashed is_local removal into the first commits. So like it didn't
>> exist at all.
>>
>> Why did you remove it, btw? I applied the removal, because realized,
>> that if all the spaces are local, then neither of them can be sync.
>> So I banned is_sync + is_local options in the first commit. Did you
>> remove it for the same reason?
>
> If I remember correctly, your is_local check was not about local spaces, but
> rather about whether the transaction was originating from the local instance.
Yeah, also my bad. The name of my own variable confused me.
> I separated txn_limbo behaviour judging by where the limbo_entries come from.
> If they come from txn_commit_async(), this means this is a replica, and txn_limbo
> waits for confirm messages. If they come from txn_commit(), this is master, so
> txn_limbo gathers acks. It'd be better to judge by your is_local flag, I believe.
Yeah, better rely on rows content than on async vs normal commit way. Both
in txn_commit_async() and txn_commit().
> We probably should put a fixme here also.
More information about the Tarantool-patches
mailing list