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] <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
