Re: [Tarantool-patches] [PATCH] Trigger on vclock change

[Konstantin Osipov <kostja.osipov@gmail.com>]

* Georgy Kirichenko <georgy@tarantool.org> [19/11/14 22:42]:
> A replica state is described by 2 vclocks - written and committed ones. Right 
> now it is not an issue to report them both as an applier submits transaction 
> asynchronously. In addition to these two vclocks (yes, the both could be 
> transferred from the WAL thread) applier will report a reject vclock - the 
> vclock where applying breaks, and this could be done from TX. I do not like 
> the idea to split transmission between 2 threads. The write and reject vclocks 
> are used to evaluate majority whereas commit vclock instructs a whole cluster 
> that majority was already reached. The main point is that any replica member 
> could commit a transaction - this relaxes RAFT limitations and increases the 
> whole cluster durability (and it is simpler in design and implementation, 
> really). Also the new synchronous replication design has a lot of advantages 
> in comparison with RAFT but let us discuss it in another thread. If you 
> interested please ask for details as I have not enough time to write public 
> document right now.
> Returning to the subject, I would like to conclude that wal on_commit and 
> on_write triggers are good source to initiate status transmission. And the 
> trigger implemented by Maria will be replaced by replica on_commit which 
> allows us not to change anything at higher levels.

Congratulations, Georgy, maybe you even get a Turing award for
inventing a new protocol.

Wait... they don't give a Turing award for "protocols" which have
no proof and yield inconsistent results, or do they?

Meanwhile, if you have a design in mind, you could send an RFC. I
will respond to the RFC.

PS What a shame...

-- 
Konstantin Osipov, Moscow, Russia