Thank you. Does this memcached 'add' lock or 'set' lock defined in memecached client or memcached server? The reason I asked because, thread 1 from one process and thread 2 from another process tries to add and set simultaneously, will this lock happens at the memcached server or at the individual clients?
On Thu, Apr 26, 2018 at 9:26 AM dormando <[email protected]> wrote: > 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. > -- --- 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.
