Oh I see, of course. So I assume the client library automatically sends write commands to the current leader?
I wonder if there is value in setting a preferred leader, but probably that's messing too much with the Raft protocol. On Sun, Aug 20, 2017, 11:44 PM Free Ekanayaka <f...@ekanayaka.io> wrote: > Wout Mertens <wout.mert...@gmail.com> writes: > > > Very interesting! > > > > So how does it behave during conflict situations? Raft selects a winning > > WAL write and any others in flight are aborted? > > Ah yeah this is probably something that was not clear from the docs or > from my presentation. > > There can't be a conflict situation. Raft's model is that only the > leader can append new log entries, which translated to dqlite means that > only the leader can write new WAL frames. So this means that any attempt > to perform a write transaction on a non-leader node will fail with a > SQLITE_NOT_LEADER error (and in this case clients are supposed to retry > against whoever is the new leader). > > I'm going to add this to the FAQ. > > > And when not enough nodes are available, writes are hung until > > consensus? > > Yes, but there's a (configurable timeout). It's not possible to *not* > have timeout (although you can set it really really high of course :) > > > I won't be able to use it due to Go but it's great to know that this is > on > > the horizon of possibilities… Very nice! > > Yeah I think Go is somehow limiting, but hopefully once Raft libraries > mature in C/Raft, dqlite can act as reference/prototype. > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
