dustin at spy.net
Mon May 14 16:57:03 UTC 2007
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the memcached