Open Stack

A new put can only succeed if it has successfully updated a full majority of the replicas (typically 2 out of 3).
Therefore two different updates cannot concurrently succeed, one of them has to know that it is the later transaction.

If you aren't forcing a Get to reference all servers, using the option Stephen mentioned, then you MAY get an
old version before the replication process is complete. That is what is meant by "eventual consistency".

For most users, it is not worth slowing down a get for the slight risk of not fetching *the* latest update,
but each user can decide that for themselves.

Requiring *full* consistency, where the next get is guaranteed to get the most recent PUT, would result in
Far longer worst-case  transaction times. Something like a switch reset would delay a transaction rather than
Queuing up a synchronization of the 3rd server after it reconnects.

If you're trying to do a distributed database  a Cloud Storage API might not be the best solution for you. But
Most applications will deal with a slight amount of uncertainty very well. Your application had to work even if
you fetched an object a millisecond *before* someone else updated it, right? How important can it be that
you not get the old version a millisecond *after* it was updated?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120120/975d8c81/attachment.html>