Well I haven't read the lease paper yet. Ryan, can folks more familiar
with the actual implementation have a look through it maybe?

On Thu, 17 Apr 2014, Zhiwei Chan wrote:

>
> I m working on a trading system, and getting stale data for the system is 
> unaccepted at most of the time. But the high throughput make it
> impossible to get all data from mysql. So i want to make it more reliable 
> when use memcache as a cache. Facebook's paper "Scaling Memcache at
> Facebook" mentions a method called ‘lease' and 'mcsqueal', but the mcsqueal 
> is difficult for my case, because it is hard to get the key for mysql.
>
> Adding the 'strong cas' feature is devoted to solve the following typical 
> problems, client A and Client B want to update the same key, and A(set
> key=>1)update database before B(set key=>2):
> key not exist in cache: (A get-miss)->(B get-miss)->(B set key=2) -> (A set 
> key=1);
> or key exist in cache: (A delete key)->(B delete key)->(B set key=2) -> (A 
> set key=1);
> Some thing Wrong! the key=2 in database but key=1 in cache.
>
> It is possible to happen in a high concurrent system, and i don't find a way 
> to solve it with the current cas method. So i add two command 'getss'
> and 'deletess', they will create a lease and return a cas-unique, or tell the 
> client there already exist lease on the server. the client can do
> something to prevent stale data. such as wait, or invalidate the pre-lease.
> I also think the lease is a concept of 'dirty lock', because anybody try to 
> update it will replace itself expiration to the lease's expiration(the
> lease's expiration time should be very short), so in the worst case(low 
> probability), the stale data only exist in cache for a short time. It is
> accepted for most app in my case.
>
> For more detail information, please read doc/strongcas.txt. And hoping for u 
> guys suggestion ~_~
>
>  i have created a pull request on github.
> https://github.com/memcached/memcached/pull/65
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups 
> "memcached" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to memcached+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to memcached+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to