Thanks for reaching out to figure things out; I do need to improve the documentation still.
Good luck! On Wed, 25 Apr 2018, sachin shetty wrote: > Sorry I might have misunderstood. > I'm clear now. Thanks for clearing all my doubts and providing extensive info > on the > stampeding problem. It did help a lot. > In fact, the precedence did help to find the better solution. Thanks once > again. > > Cheers > > On Thursday, 26 April 2018 11:43:21 UTC+5:30, Dormando wrote: > You're way way over thinking this. > > I originally gave two examples, one was literally just the ADD and SET > commands, and the other is a wiki page that solves further issues, which > you should ignore for now. > > Again, memcached server is *atomic* for key manipulations. the server > works exactly as I described, no matter what you do or how you access > it. > > On Wed, 25 Apr 2018, sachin shetty wrote: > > > 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 Thursday, 26 April 2018 09:26:30 UTC+5:30, Dormando 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 > > > > > 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+...@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+...@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+...@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.
