<div class="gmail_quote">On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In a single thread, using a single database session, then a read after<br>
successful commit is guaranteed to read a version of the database<br>
that existed after that commit.<br></blockquote><div><br></div><div>Ah, I'm relieved to hear this clarification - thanks.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd like to see actual examples where that will matter. Meanwhile making<br>
all selects wait for the cluster will basically just ruin responsiveness<br>
and waste tons of time, so we should be careful to think this through<br>
before making any blanket policy.<br></blockquote><div><br></div><div>Matthew's example earlier in the thread is simply a user issuing two related commands in succession:</div><div><br></div><div>$ nova aggregate-create</div><div>$ nova aggregate-details</div><div><br></div><div>Once that fails a few times, the user will put a poorly commented "sleep 2" in between the two statements, and this will "fix" the problem most of the time.  A "better" fix would repeat the aggregate-details query multiple times until it looks like it has found the previous create.</div><div><br></div><div>Now, that sleep or poll is of course a poor version of something you could do at a lower level, by waiting for reads+writes to propagate to a majority quorum.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd also like to see consideration given to systems that handle<br>
distributed consistency in a more active manner. etcd and Zookeeper are<br>
both such systems, and might serve as efficient guards for critical<br>
sections without raising latency.<br></blockquote><div><br></div><div>+1 for moving to such systems.  Then we can have a repeat of the above conversation without the added complications of SQL semantics ;)</div><div><br></div><div> - Gus</div></div>