Great. Thanks John!! On Fri, Aug 8, 2014 at 1:48 PM, John Dickinson <m...@not.mn> wrote: > 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 >
_______________________________________________ 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
