Hey, ADD sets an item *only if it doesn't currently exist*.
If you want thread 2 to be authoritative after updating the DB, you need to use a SET. If you don't care and only ever want the first thread to win, you can always use ADD. On Wed, 25 Apr 2018, sachin shetty wrote: > 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. > > 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.
