Deletes Are Driving Me Crazy

Matthew Glubb matt at zgroupplc.com
Wed Jan 11 18:01:02 UTC 2006


Okay, I guess I can expand a little :)

You are right to guess that I am using memcache as a queue of sorts.  
It's network related.

Each client has a maximum of N key/value pairs in the memcache.  
Multiple, concurrent requests may be arriving from the same client.  
Every client uses the same key prefix for all of there keys ie.  
prefix_[0 to N-1]. If a client tries to overwrite one of those key/ 
value pairs once they have been assigned the request is denied, hence  
the requirement for using add rather than set. If a client session  
ends, all N key/value pairs should be deleted. If the same client  
then starts another session they should be able to recreate up to N  
key/value pairs using the same key names but containing different  
values.

I have multiple red hat boxes running lighttpd and load-balanced fast- 
cgi php 5.0.5 modules with John's mcache extension 1.2.0 beta10  
compiled against libmemcache-1.4.0.b9. Memcached is version 1.1.12.

Sometimes it works, sometimes it doesn't. It seems to me that deleted  
keys are not always deleted 'straightaway'.

Matt

On 11 Jan 2006, at 17:24, Jeff Rodenburg wrote:

> On 1/11/06, Matthew Glubb <matt at zgroupplc.com> wrote:
>>
>> I simply wish to be able to delete a key that has a zero expiry
>> period and then immediately be able to add a key of the same name.
>> The reason that I cannot use set is because if it already exists in
>> the cache I do not want to replace the value.
>>
>
> I have a somewhat similar requirement, but I'm curious about this  
> specific
> approach.  It sounds as if an object may go into the cache with a  
> given key,
> but in some scenarios if that key is already in use, that object  
> would use a
> different key in the cache.  Is that accurate?
>
> This sound as if you might be using the cache as a queue or  
> something to
> delineate prioritization or ordering.
>
> I know this doesn't resolve the particular add/delete/add scenario,  
> but I'm
> curious about the requirements side.
>
> cheers,
> j



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/>

PLEASE NOTE ZGROUP IS NOT LIABLE  FOR ANY DAMAGES,  MALFUNCTION, OR LOSS
OF DATA,  CAUSED AS A RESULT OF FOLLOWING  ANY  ADVICE  ENCLOSED IN THIS
EMAIL. ANY CHANGES SHOULD BE CARRIED OUT AT YOUR OWN RISK.

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>





More information about the memcached mailing list