[Tarantool-patches] [PATCH] limbo: introduce request processing hooks

[Vladislav Shpilevoy]

>>>> And you should not do that. Before WAL write there should no be any
>>>> changes. **Zero changes before WAL write**. Before you write to WAL,
>>>> you can only validate requests. Using `const struct txn_limbo *`. With
>>>> zero changes.
>>>
>>> If we write screwed PROMOTEs request into our WAL then this patch is not
>>> needed at all.
>>
>> Я не говорил, что надо писать плохие PROMOTE. Я говорю, что ты можешь
>> их отсеивать с ошибкой не делая никаких изменений состояния лимба до
>> записи в WAL.
> 
> Да вот похоже, что не могу (если без локов).
> 
>> Я так понимаю, ты пытаешься как-то защититься от того, что одновременно
>> пришло несколько PROMOTE, и пока один пишется, надо остальные сразу
>> отлупить? Так делает для обычных данных аплаер - он двигает vclock
>> кластера до записи в WAL, и копирует его в replicaset.vclock если
>> запись удалась. При этом если во время записи придут еще такие же
>> транзакции от других инстансов, то они сразу отфильтруются.
>>
>> Но в лимбе нет такой проблемы, что все надо делать параллельно. При
>> любых "паралеллельных" промоутах, конфирмах и прочих изменениях
>> состояния лимба лучше просто брать на него лок и все. Эти вещи
>> параллельно от разных инстансов приходить не должны во время нормальной
>> работы, так что это по перфу самого частого случая не ударит нисколько,
>> а код упростит значительно.
> 
> Ну технически да, можно лок\латч взять, для модификаций промота и
> вклок термов. Это уберет необходимость infly модификаций, что я
> сделал для filter phase. Я наоборот, хотел избежать локов, но давай
> действительно попробуем с локами. Если вдруг будет жесткая просадка,
> то вернемся на схему с inlfy переменными и их обновлениями после
> записи в вал. Я пока бранч старый удалять не буду.

Сейчас стабильность превыше всего. Если патч с локами будет гораздо
проще, то надо идти с ним. Иначе мы еще ревью будем проходить и баги
находить месяц - столько времени нет.