> On Nov 19, 2014, at 3:47 PM, Ryan Moats <rmo...@us.ibm.com> wrote: > > > > BTW, I view your examples from oslo as helping make my argument for > me (and I don't think that was your intent :) ) >
I disagree with that as IMHO the differences in producing MM in the app layer against arbitrary backends (Postgresql vs. DB2 vs. MariaDB vs. ???) will incur a lot more “bifurcation” than a system that targets only a handful of existing MM solutions. The example I referred to in oslo.db is dealing with distinct, non MM backends. That level of DB-specific code and more is a given if we are building a MM system against multiple backends generically. It’s not possible to say which approach would be better or worse at the level of “how much database specific application logic do we need”, though in my experience, no matter what one is trying to do, the answer is always, “tons”; we’re dealing not just with databases but also Python drivers that have a vast amount of differences in behaviors, at every level. On top of all of that, hand-rolled MM adds just that much more application code to be developed and maintained, which also claims it will do a better job than mature (ish?) database systems designed to do the same job against a specific backend. > > > > My reason for asking this question here is that if the community > > > wants to consider #2, then these problems are the place to start > > > crafting that solution - if we solve the conflicts inherent with the > > > two conncurrent thread scenarios, then I think we will find that > > > we've solved the multi-master problem essentially "for free”. > > > > Maybe I’m missing something, if we learn how to write out a row such > > that a concurrent transaction against the same row doesn’t throw us > > off, where is the part where that data is replicated to databases > > running concurrently on other IP numbers in a way that is atomic > > come out of that effort “for free” ? A home-rolled “multi master” > > scenario would have to start with a system that has multiple > > create_engine() calls, since we need to communicate directly to > > multiple database servers. From there it gets really crazy. Where’sall > > that ? > > Boiled down, what you are talking about here w.r.t. concurrent > transactions is really conflict resolution, which is the hardest > part of implementing multi-master (as a side note, using locking in > this case is the equivalent of option #1). > > All I wished to point out is that there are other ways to solve the > conflict resolution that could then be leveraged into a multi-master > scenario. > > As for the parts that I glossed over, once conflict resolution is > separated out, replication turns into a much simpler problem with > well understood patterns and so I view that part as coming > "for free." > > Ryan > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
