On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum <cl...@fewbar.com> wrote: > > In a single thread, using a single database session, then a read after > successful commit is guaranteed to read a version of the database > that existed after that commit. >
Ah, I'm relieved to hear this clarification - thanks. I'd like to see actual examples where that will matter. Meanwhile making > all selects wait for the cluster will basically just ruin responsiveness > and waste tons of time, so we should be careful to think this through > before making any blanket policy. > Matthew's example earlier in the thread is simply a user issuing two related commands in succession: $ nova aggregate-create $ nova aggregate-details 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. 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. I'd also like to see consideration given to systems that handle > distributed consistency in a more active manner. etcd and Zookeeper are > both such systems, and might serve as efficient guards for critical > sections without raising latency. > +1 for moving to such systems. Then we can have a repeat of the above conversation without the added complications of SQL semantics ;) - Gus
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev