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
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
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
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
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
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
i want to add this group . plz add on this group
On Wednesday, April 25, 2018 at 2:05:41 PM UTC+5:30, 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.
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
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
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.
10 matches
Mail list logo
