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
