matt at zgroupplc.com
Mon May 14 17:03:52 UTC 2007
-----BEGIN PGP SIGNED MESSAGE-----
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,
> 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
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 zgroupplc.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
-----END PGP SIGNATURE-----
More information about the memcached