You are describing one of the ways that Swift does eventual consistency. In the scenario you describe, it is indeed possible to get the older version of the object on a read. There is no whole-cluster invalidation of an object. Swift's behavior here gives you high availability of your data even when you have failures in your cluster. Your proposed scenario can happen if a server fails after the first write and is restored after the second write, but before the read.
However, there are a few things you can do on the client side. One option is to keep track of the etag of the data you've sent. That way you can verify that you're getting back what you expected to get back. Another option would be to use a read request with the If-[Un]Modified-Since header (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html). --John On Aug 8, 2014, at 1:18 PM, Shrinand Javadekar <shrin...@maginatics.com> wrote: > Hi, > > I have a question regarding the way object overwrites work in the > absence of versioning. I couldn't find this info in the documentation. > > Consider the case when I have an object O already present in the Swift > cluster. There are N replicas of this object. When a new PUT request > that overwrites object O is returned, Swift guarantees that the new > object, say O' got written successfully to N/2 + 1 object servers. But > there could be some replicas that still have the older object O. > > Does Swift have a way of invalidating the older object O on all object > servers? > > If there is a GET request for object O, immediately after the > overwrite, does Swift guarantee that the older object O cannot be > returned? > > Thanks in advance. > -Shri > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
