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" <kevinth.f...@gmail.com> 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+unsubscr...@googlegroups.com. > 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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
