Add a CASStore trait

[johnynek]

something like:

trait CASStore[T:Equiv, K, V] {
  def get(k: K): Future[(V, T)]
  // returns the token immediately before
  // and the value. If the result equiv(Token, T), then the swap happened 
  def cas(token: T, kv: (K, V)): Future[(V,T)] 
}

With this, we can build a local cache of tokens and values and do Mergeable with 1 roundtrip, rather than 2 in Memcache etc..

Note, this does not put an Option on the returns. If missing values are allowed, use Option[V].

Question: does multiCas make sense? We can always add it, but how many systems can optimize it?

[ianoc]

Sounds pretty cool. I believe redis can support it via its scripting API. But not sure of any other ones that could. (Scripts are executed atomically, so you could return key's for which the swap wasn't possible).

[rubanm]

I think this will work great with memcache if the locally cached tokens are usually going to be current.

Redis doesn't use tokens for cas. Instead, it lets you "watch" the key for any updates by other threads while you try to make an update. The same applies to scripts as well I think. So we may not need a token there - http://redis.io/topics/transactions#cas

Is there a way to model this trait for stores that do not use cas tokens?

[avibryant]

This seems to overlap with my (sadly abandoned) UpdateableStore PR, right? #119

[rubanm]

Ah, yes. UpdateableStore sounds like the more appropriate place for redis updates.

UpdateableStore was conceived for read-modify-writes. On the other hand, CASStore seems to be separating the three (get for reads, modify, and then cas for writes) by optimizing for cases where locally cached tokens are current.

I can see a MemcacheUpdateableStore built on top of a MemcacheCASStore though.

[rubanm]

Having said that, +1 for the trait.
Along with memcache, twitter's internal key-value store also supports CAS so this will be really useful.