Open Stack

On Mon, Jan 30, 2012 at 5:51 PM, Mark Nottingham <mnot at mnot.net> wrote:

>
> On 31/01/2012, at 4:45 AM, Caitlin Bestler wrote:
>
> > Mark Nottingham asked:
> >
> >> Why not just use
> >>  Cache-Control: no-cache?
> >
> >> That way, intervening caches will do the right thing too...
> >
> >
> > Even with no caching anywhere you still have N replicas (typically
> three) that will be updated in an arbitrary order,
> > and clients that read from any one of those replicas.
>
> Right.. all that I'm saying is that the semantics of CC: no-cache are
> effectively the same as X-Newest, and have the nice side effect of busting
> any intermediary caches along the way.
>
>
> > Unless  you implement a draconian global locking scheme there is nothing
> you can do to prevent a client from reading
> > a copy that has just been rendered obsolete by another client completing
> the edit of the (N+1)/2th replica.
>
> ??
>
> > If the goal is to validate with all N servers then this should be a
> special transaction. The benefits of caching should remain
> > In place for typical reads.
>
> and they will, if you don't use CC: no-cache on them.
>
> Regards,
>
>
>
The current semantics allow you to do

1) the the most recent cached copy, using the http caching mechanism. This
will ignore any updates to the swift cluster, as long as the cache is not
stale

2) get a recent copy from swift  (when setting no cache)

3) do a quorum call on all the storage nodes to get the most accurate
answer swift can provide.



You're proposing that 2 & 3 are the same, since they're both different than
1. But their performance implications on 2 & 3 are quite different.

--
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120130/1114a037/attachment.html>