Memcached is internally atomic on key operations. If you add and set at the same time, the set will effectively always win since they are serialized.
1) add goes first. set overwrites it. 2) set goes first. add will fail. On Wed, 25 Apr 2018, sachin shetty wrote: > Cool. > So let me assume the below scenario and correct me if I'm wrong here. > > Say thread 1 always does add and thread 2 always does set. Will there be any > race conditions when both these threads do add and set simultaneously? What > I mean is say thread1 does add and holds 'add' lock and if at the same time > thread 2 comes for the set operation, how 'set' lock and 'add' lock is > handled here? > > > On Thursday, 26 April 2018 06:58:27 UTC+5:30, Dormando wrote: > 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 > > > [email protected]. > > > 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 [email protected]. > > 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
