Ah, to clarify, there is only one "master" at any point in time. So this isn't a "multi-master" scenario where each node keeps committing locally and then somehow merging the results later. Rather, each node knows if it's the master or slave (or a variety of other states). If it's a master, it organizes the two-phase distributed commit. If it's a slave, it escalates to the master. And if it's something else, then it just holds on to the request and waits until it's either a slave or a master.
-david On Wed, Oct 31, 2012 at 2:09 AM, Chris Peachment <ch...@ononbb.com> wrote: > On Wed, 2012-10-31 at 00:49 +0700, David Barrett wrote: > > Thanks Alek! Yes, we're definitely planning on it, just trying to > > find the right time. We don't want to go through the work to open > > source it only to be greeted with silence. Might you be interested in > > using it in an actual deployed environment, or just studying it? > > > > > Your proposal to open source the replication method used by Expensify > has me interested. My application of interest is much smaller than > yours, just a handful of remote clients that risk loss of connectivity > but wish to continue with database updates during the downtime. > > Aside from the details of protocol usage and statement packaging, the > concern for collisions during merge is a particular issue of interest. > > Chris > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
