memcached

[Dustin Sallings]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070514/305d5557/attachment.html