Thank you for the reply. Can this add be used always, I mean during an update as well? What could be the potential disadvantage of this? So if two thread does an update using add, still lock hold well in this sceanrio?
Thanks, Sachin On Wednesday, 25 April 2018 14:13:40 UTC+5:30, Dormando wrote: > > Hey, > > Two short answers: > > 1) thread 1 uses 'add' instead of 'set' > 2) thread 2 uses 'set'. > > via add, a thread recaching an object can't overwrite one already there. > > > https://github.com/memcached/memcached/wiki/ProgrammingTricks#avoiding-stampeding-herd > > > for related issues. using an advisory lock would change the flow: > > a. thread 1 gets a miss. > b. thread 1 runs 'add lock:key' > c. thread 1 wins, goes to db > d. thread 2 updates db. tries to grab key lock > e. thread 2 fails to grab key lock, waits and retries > > etc. bit more chatter but with added benefit of reducing stampeding herd > if that's an issue. > > On Wed, 25 Apr 2018, sachin shetty wrote: > > > There is a scenario where a cache gets updated by two threads like the > instance > > mentioned below > > > > a. thread 1 looks at the memcache key and gets a miss > > b. thread 1 falls back to the database > > c. thread 2 changes the database value > > d. thread 2 updates the memcache key with the new value > > e. thread 1 sets the old database value into memcache > > > > I know this scenario is application specific. But the question I have is > if possible > > there is an option to say the current value's timestamp is older than > the one already in > > cache, then memcached should ignore the new entry. This could solve race > condition as > > mentioned above. Suppose I say take the timestamp as the version then > memcached server > > could make use of this to verify whether new entry coming is older than > the already > > current one present. > > > > Handling at the client would be performance intensive because of every > time fetching an > > existing value from the cache to check the timestamp. > > > > Are there any handlers for this to solve. Would be very helpful if you > could provide any > > inputs on this. > > > > > > Thanks, > > Sachin > > > > > > -- > > > > --- > > 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 <javascript:>. > > 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.
