I'll take a look at the API and behavior and provide feedback. I'll also ping our former server guys to see if they can take a look at the implementation.
Cheers, ~Ryan On Sun, Apr 20, 2014 at 12:23 AM, dormando <dorma...@rydia.net> wrote: > 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. > -- --- 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.
