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

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

Reply via email to