-----BEGIN PGP SIGNED MESSAGE-----
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 :)
Regards,
Matt
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: <http://www.zgroupplc.com/>
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 <[EMAIL PROTECTED]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFGSJZ7yI6MkdKPngkRAs5RAKCL4y5gKl5uB9ZMT4W+zMVclgdo8gCgmQjU
q4UP1FxIiG2c3QuqHqyS3X0=
=TeVw
-----END PGP SIGNATURE-----
