Open Stack

Excerpts from Adam Young's message of 2013-07-10 19:14:45 -0700:
> On 07/09/2013 09:51 PM, Robert Collins wrote:
> > PostgreSQL doesn't do gap locks, but instead you have to deal with 
> > http://wiki.postgresql.org/wiki/SSI : the transaction that is deleting 
> > 1M rows, for instance, will have a query that may return rows which 
> > another transaction is adding; if so one of the two will be rolled 
> > back. This is in many ways equivalent from the point of view of 
> > writing good SQL that will work well on both systems.
> 
> This is not a problem with token cleanup path, though. Tokens are 
> cleaned up based on expiry time, a value that is written and never 
> changed.  Tokens should never be removed from the database until their 
> expiry has been hit, or valid tokens will be denied.
> 

Note that when the memory limit is reached, memcached will delete the
least recently used key in a slab that is full, whether it has reached
its TTL or not. If backends have to guarantee tokens will live for the
life of the token, memcached is inappropriate without ensuring it never
fills up or using the -M flag, which will then break a basic assumption
that items over TTL will be removed to free up space.

I think at some point clients have to expect tokens that should still
be valid might not be, and look at "invalid token" as a re-triable error.