c* 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
> &g
gt; 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
> a
gt; 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
> a
.
> 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
>
er 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 upd
ck, 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
> > m
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.
