<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 19, 2014, at 3:47 PM, Ryan Moats <<a href="mailto:rmoats@us.ibm.com" class="">rmoats@us.ibm.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><p class=""><font size="2" face="sans-serif" class="">> </font><br class="">
<tt class=""><font size="2" class="">BTW, I view your examples from oslo as helping make my argument for</font></tt><br class="">
<tt class=""><font size="2" class="">me (and I don't think that was your intent :) )</font></tt><br class=""></p></div></div></blockquote><div><br class=""></div>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. </div><div><br class=""></div><div>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.</div><div><br class=""></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">
<br class="">
<tt class=""><font size="2" class="">> > My reason for asking this question here is that if the community <br class="">
> > wants to consider #2, then these problems are the place to start <br class="">
> > crafting that solution - if we solve the conflicts inherent with the<br class="">
> > two conncurrent thread scenarios, then I think we will find that <br class="">
> > we've solved the multi-master problem essentially "for free”.</font></tt><br class="">
<tt class=""><font size="2" class="">> <br class="">
> Maybe I’m missing something, if we learn how to write out a row such<br class="">
> that a concurrent transaction against the same row doesn’t throw us <br class="">
> off, where is the part where that data is replicated to databases <br class="">
> running concurrently on other IP numbers in a way that is atomic <br class="">
> come out of that effort “for free” ? A home-rolled “multi master” <br class="">
> scenario would have to start with a system that has multiple <br class="">
> create_engine() calls, since we need to communicate directly to <br class="">
> multiple database servers. From there it gets really crazy. Where’sall that ?</font></tt><br class="">
<br class="">
<tt class=""><font size="2" class="">Boiled down, what you are talking about here w.r.t. concurrent</font></tt><br class="">
<tt class=""><font size="2" class="">transactions is really conflict resolution, which is the hardest</font></tt><br class="">
<tt class=""><font size="2" class="">part of implementing multi-master (as a side note, using locking in</font></tt><br class="">
<tt class=""><font size="2" class="">this case is the equivalent of option #1). </font></tt><br class="">
<br class="">
<tt class=""><font size="2" class="">All I wished to point out is that there are other ways to solve the</font></tt><br class="">
<tt class=""><font size="2" class="">conflict resolution that could then be leveraged into a multi-master</font></tt><br class="">
<tt class=""><font size="2" class="">scenario.</font></tt><br class="">
<br class="">
<tt class=""><font size="2" class="">As for the parts that I glossed over, once conflict resolution is</font></tt><br class="">
<tt class=""><font size="2" class="">separated out, replication turns into a much simpler problem with</font></tt><br class="">
<tt class=""><font size="2" class="">well understood patterns and so I view that part as coming</font></tt><br class="">
<tt class=""><font size="2" class="">"for free."</font></tt><br class="">
<br class="">
<tt class=""><font size="2" class="">Ryan</font></tt></p></div>_______________________________________________<br class="">OpenStack-dev mailing list<br class=""><a href="mailto:OpenStack-dev@lists.openstack.org" class="">OpenStack-dev@lists.openstack.org</a><br class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br class=""></div></blockquote></div><br class=""></body></html>