Matthew Glubb matt at
Mon May 14 17:03:52 UTC 2007

Hash: SHA1

I regularly use a locking mechanism with memcache. Fortunately in my  
situation, if a process fails to acquire a lock (usually due to a  
lock wait timeout), it isn't the end of the world as its self healing.

Depending on what you want to do, your mileage may vary. I would  
hesitate in waiting more than 10-20 milliseconds in a lock wait. But  
then, I am using PHP which is disastrous for concurrent programming : 
( The next version is in Python :)



On 14 May 2007, at 17:57, Dustin Sallings wrote:

> On May 14, 2007, at 8:25 , Julio Leyva wrote:
>> We have a transaction that must lock a key in a table and no any  
>> other parallel transaction can access that key until the first  
>> transaction is finished.
>> We think that process will be faster using memcached.
> 	The best that memcached could offer is a counter you could do  
> something like a spinlock on.  That may very well be worse.
> 	It should be possible to parallelize your transactions, though.   
> Should all read processes stop just because something has indicated  
> it may be changing in another process?  If you allow concurrent  
> reads, then you memcache can help, but you can likely do away with  
> the lock altogether.
> 	If you can defer  your concurrency checking to the *end* of the  
> transaction, all you have to do is roll back whatever transaction  
> didn't win and start it over.  I used to do something like this for  
> a relatively concurrent system.  In my case, the number of  
> transaction collisions was small enough that I never even bothered  
> to replay the loser.  I'd just roll it back and return an error and  
> let the other side deal with the failure.  I tracked all of the  
> fields that changed, so resolving it would've been pretty simple,  
> though.
> -- 
> Dustin Sallings

m a t t h e w   g l u b b

Z Group PLC

Tel: +44 (0) 8700 111 173
Fax: +44 (0) 8707 051 393
Txt: +44 (0) 7800 140 877
Web: <>

This  email  and  any  files  transmitted  with it are  confidential and
intended solely for the use of the individual or entity to whom they are
addressed.  The opinions  expressed in this mail are those of the author
and do not necessarily  represent the views of the company.  If you have
received this email in error please notify <service at>

Version: GnuPG v1.4.1 (Darwin)


More information about the memcached mailing list