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?
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
