You would be better off solving your problem rather than reducing the likelihood of failure and still have the problem. You could for instance use the cas operation if you are going to replace stuff etc.
Trond On Sep 25, 2013 3:40 PM, "Kevin Fang" <[email protected]> wrote: > But I think if I can set the timeout for 1 or 2 seconds the probability of > the race condition should be much less. > > Thanks, > Kevin > > On Wednesday, September 25, 2013 9:25:50 PM UTC+8, Trond Norbye wrote: >> >> A distributed system may always have race conditions and you need to find >> a solution for them. Your delayed delete would not solve that because you >> don't know how slow the other stuff may be. >> >> Trond >> On Sep 25, 2013 3:13 PM, "Kevin Fang" <[email protected]> wrote: >> >>> Hi guys, >>> >>> I have one question about the 'delete' command. >>> Before 1.4.0, the command used to be >>> delete <key> [<time>] [noreply]\r\n >>> there is a <time> parameter which supports lingering delete. >>> But after 1.4.0 the feature was completely removed. Now there is no >>> <time> parameter. >>> >>> However, I think this parameter is useful. It could avoid the data >>> inconsistency that caused by the reorder of 'delete' and 'set' operation. >>> Think about this senario. >>> 1. App server A 'get' key k1 from the cache server. Not exist. It's a >>> Cache miss >>> 2. App server A query database. Then try to 'set' the k1 to the cache >>> server >>> 3. App server B update the record related to k1 in the database. Then >>> try to 'delete' k1 on all cache servers. >>> 4. For some network issue the 'set' operation sent by A is very slow. It >>> reaches the cache after the 'delete' operation sent by B. >>> 5. After the 'set' operation. The value of k1 becomes stale data, and >>> may never be updated any more. >>> >>> My question is. If there is no <time> parameter for delete operation. >>> How to avoid the above senario? What's the best practice? >>> >>> Thanks, >>> Kevin >>> >>> -- >>> >>> --- >>> 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+...@**googlegroups.com. >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>> . >>> >> -- > > --- > 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 [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- --- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
