[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