... or you couldd use a concatenation of ur server ID/timestamp/query/unique client variable(s)/session.... etc.. (all hashed) as part of your (hashed) key... there's countless ways to make ur key unique... even in ur situation!!!
On 13 October 2010 19:11, Adam Lee <[email protected]> wrote: > Yeah, we also have used this as a sort of crude locking mechanism on a site > under fairly heavy load and have never seen any sort of inconsistency-- as > dormando said, I'd make sure your configuration is correct. Debug and make > sure that they're both indeed setting it on the same server. Or, if that's > not possible, whip up a small script that iterates through all of your > servers and see if the key exists on multiple servers. > > On Wed, Oct 13, 2010 at 1:47 PM, dormando <[email protected]> wrote: > >> > Hi everyone, >> > >> > we have the following situation: due to massive simultaneous inserts >> > in mysql on possibly identical primary keys, we use the atomic >> > memcache add() as a semaphore. In a few cases we observed the >> > behaviour, that two simultaneous add() using the same key from >> > different clients both returned true (due to consistent hashing the >> > key has to be on the same machine). >> > >> > Is it now possible, that the multithreaded memcached does return true >> > on two concurrent add() on the same key, if the requests are handled >> > by two different threads on the same machine? >> >> It should not be possible, no. Be sure you've disabled the client >> "failover" code. >> > > > > -- > awl >
