PECL memcache extension

Olivier Favre-Simon olivier.favre-simon at club-internet.fr
Tue Feb 7 13:34:45 UTC 2006


Yep.

Then may be you have to give short life, say 1 or 2 minutes, to keys you
don't want to be stale...

Not deterministic at all, but that way stale keys on the A server would
delete themselves if server B is up for at least this expiry time (so
live keys get directed to it again).

BTW thanks for bringing this issue. It's clear now this situation might
also be a problem for my apps with some "sensitive" keys, at least in
theory since my memcached processes/servers are hardly down...


Timo Ewalds wrote:
>
>
> Paul G wrote:
>
>>
>> ----- Original Message ----- From: "Don MacAskill" <don at smugmug.com>
>> To: "memcached mail list" <memcached at lists.danga.com>
>> Cc: <mikl at php.net>
>> Sent: Friday, February 03, 2006 5:37 PM
>> Subject: PECL memcache extension
>>
>>
>>
>> -- snip --
>>
>>> If "set key1" is destined to ServerB's buckets, but ServerB fails, I
>>> don't want "key1" being redirected to ServerA instead.  Why? 
>>> Because when ServerB comes online, I now have "key1" in two places,
>>> and one of them will now potentially get out of date.  Should
>>> ServerB fail again before "key1" has expired, calls to "get key1"
>>> will return old stale data from ServerA instead of fresh data or no
>>> result.
>>>
>>> Make sense?  Am I doing something wrong?  Can the PECL extension
>>> work in this fashion?
>>
>>
>> maybe i'm missing something, but i don't think the case you're trying
>> to protect against is actually going to occur. once serverB comes
>> back online (and gets added to the rotation, which gets rehashed),
>> all further queries for key1 will again be run against it, whether
>> it's set or get. sure, you get a stale entry for it on serverA, but
>> if it never gets queried for it again, who cares?
>>
>> -p
>>
> You don't care if all goes well, but if serverB fails again, it will
> drop back to serverA again, which still has stale data which it is
> perfectly happy to serve as if it was not stale.
>
> Timo
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.danga.com/pipermail/memcached/attachments/20060207/48e5c5b1/signature.pgp


More information about the memcached mailing list