<div>As I understood from the memcache docs and code deltes were never meant to be "straight away" but on a "when resources are available" basis.</div>
<div> </div>
<div>I do not understand how you expect to use add because it doesn't overwrite existign keys when you have just deleted them beforehand.</div>
<div> </div>
<div>If your code is more like:</div>
<div> </div>
<div>ADD</div>
<div>if(condition){</div>
<div>DELETE</div>
<div>}</div>
<div>ADD</div>
<div> </div>
<div>you might change it to:<br> </div>
<div>ADD</div>
<div>if(condition){</div>
<div>SET</div>
<div>}else{</div>
<div>ADD</div>
<div>}</div>
<div> </div>
<div>To do what you want. How can you not use set instead of delete-add?</div>
<div> </div>
<div>SN<br> </div>
<div><span class="gmail_quote">On 1/11/06, <b class="gmail_sendername"><a href="mailto:memcached-request@lists.danga.com">memcached-request@lists.danga.com</a></b> <<a href="mailto:memcached-request@lists.danga.com">memcached-request@lists.danga.com
</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Send memcached mailing list submissions to<br> <a href="mailto:memcached@lists.danga.com">memcached@lists.danga.com
</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> <a href="http://lists.danga.com/mailman/listinfo/memcached">http://lists.danga.com/mailman/listinfo/memcached</a><br>or, via email, send a message with subject or body 'help' to
<br> <a href="mailto:memcached-request@lists.danga.com">memcached-request@lists.danga.com</a><br><br>You can reach the person managing the list at<br> <a href="mailto:memcached-owner@lists.danga.com">memcached-owner@lists.danga.com
</a><br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of memcached digest..."<br><br><br>Today's Topics:<br><br> 1. Re: Deletes Are Driving Me Crazy (Matthew Glubb)
<br> 2. Re: Deletes Are Driving Me Crazy (Fabian Thylmann)<br> 3. Re: Deletes Are Driving Me Crazy (Matthew Glubb)<br> 4. Re: Deletes Are Driving Me Crazy (Jeff Rodenburg)<br> 5. Re: Deletes Are Driving Me Crazy (Matthew Glubb)
<br> 6. Re: Deletes Are Driving Me Crazy (Greg Whalin)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 11 Jan 2006 12:09:41 +0000<br>From: Matthew Glubb <
<a href="mailto:matt@zgroupplc.com">matt@zgroupplc.com</a>><br>Subject: Re: Deletes Are Driving Me Crazy<br>To: <a href="mailto:memcached@lists.danga.com">memcached@lists.danga.com</a><br>Message-ID: <<a href="mailto:A841A769-B1E8-4C22-B4F7-9A89167DE79B@zgroupplc.com">
A841A769-B1E8-4C22-B4F7-9A89167DE79B@zgroupplc.com</a>><br>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed<br><br>Thanks for the reply, but no, that is not want I want. I need to know<br>that when I delete an item, it is deleted. I need to be able to use
<br>add because there are other situations where I want to prevent the<br>possibility of overwriting a value. 'add' is a great way to defend<br>against that situation.<br><br>Matt<br><br>On 11 Jan 2006, at 11:39, Fabian Thylmann wrote:
<br><br>> Hi Matt,<br>><br>> what you probably want is<br>><br>> set(key, val)<br>><br>> which will set a new value for key even if it exists.<br>><br>> Fabian<br>><br>><br>> Matthew Glubb wrote:
<br>><br>>> Happy New Year to you all.<br>>><br>>> I am sorry if this has been covered before but I have trawled<br>>> through the list archives and cannot find a definitive solution.<br>>>
<br>>> I would really like to know how to:<br>>><br>>> add(key, val)<br>>> delete(key)<br>>> add(key, val)<br>>><br>>> Just seems to plain not work (all adds have zero expiration).
<br>>><br>>> If I:<br>>><br>>> add(key, val)<br>>> delete(key, 1)<br>>> sleep(2)<br>>> add(key, val)<br>>><br>>> It works.<br>>><br>>> Please can someone enlighten me as to how I may immediately delete
<br>>> a key and then add a key of the same name? I am using<br>>> memcached-1.1.12 & John McCaskey's mcache extension 1.2.0 beta10.<br>>><br>>> I noticed in the archives this thread:<br>>>
<br>>> <<a href="http://lists.danga.com/pipermail/memcached/2004-July/000688.html">http://lists.danga.com/pipermail/memcached/2004-July/000688.html</a>><br>>><br>>> This seems to be related to the problem that I am having but my
<br>>> version of memcached is almost a year later than this so I would<br>>> assume that the patch referred to in the thread is included. I'm<br>>> going to check that this isn't a problem with John's mcache
<br>>> extension but if anyone has a simple answer to my problem I'd<br>>> love to hear it.<br>>><br>>> Thanks a lot for your help :)<br>>><br>>> Matt<br>>><br>>><br>><br>
<br><br><br>m a t t h e w g l u b b<br><br>________________________________________________________________________<br>Z Group PLC<br><br>Tel: +44 (0) 8700 111 173<br>Fax: +44 (0) 8707 051 393<br>Txt: +44 (0) 7800 140 877
<br>Web: <<a href="http://www.zgroupplc.com/">http://www.zgroupplc.com/</a>><br><br>PLEASE NOTE ZGROUP IS NOT LIABLE FOR ANY DAMAGES, MALFUNCTION, OR LOSS<br>OF DATA, CAUSED AS A RESULT OF FOLLOWING ANY ADVICE ENCLOSED IN THIS
<br>EMAIL. ANY CHANGES SHOULD BE CARRIED OUT AT YOUR OWN RISK.<br><br>This email and any files transmitted with it are confidential and<br>intended solely for the use of the individual or entity to whom they are<br>
addressed. The opinions expressed in this mail are those of the author<br>and do not necessarily represent the views of the company. If you have<br>received this email in error please notify <<a href="mailto:service@zgroupplc.com">
service@zgroupplc.com</a>><br><br><br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Wed, 11 Jan 2006 16:03:24 +0100<br>From: Fabian Thylmann <<a href="mailto:fabian@toomuchmedia.com">fabian@toomuchmedia.com
</a>><br>Subject: Re: Deletes Are Driving Me Crazy<br>To: Matthew Glubb <<a href="mailto:matt@zgroupplc.com">matt@zgroupplc.com</a>><br>Cc: <a href="mailto:memcached@lists.danga.com">memcached@lists.danga.com</a>
<br>Message-ID: <<a href="mailto:43C51E3C.8060804@toomuchmedia.com">43C51E3C.8060804@toomuchmedia.com</a>><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br>Could you explain a little bit more what you are trying to do then?
<br>Maybe you are using memcached in a way it was not designed to be used.<br><br>Fabian<br><br><br>Matthew Glubb wrote:<br><br>> Thanks for the reply, but no, that is not want I want. I need to know<br>> that when I delete an item, it is deleted. I need to be able to use
<br>> add because there are other situations where I want to prevent the<br>> possibility of overwriting a value. 'add' is a great way to defend<br>> against that situation.<br>><br>> Matt<br>><br>> On 11 Jan 2006, at 11:39, Fabian Thylmann wrote:
<br>><br>>> Hi Matt,<br>>><br>>> what you probably want is<br>>><br>>> set(key, val)<br>>><br>>> which will set a new value for key even if it exists.<br>>><br>>> Fabian
<br>>><br>>><br>>> Matthew Glubb wrote:<br>>><br>>>> Happy New Year to you all.<br>>>><br>>>> I am sorry if this has been covered before but I have trawled<br>>>> through the list archives and cannot find a definitive solution.
<br>>>><br>>>> I would really like to know how to:<br>>>><br>>>> add(key, val)<br>>>> delete(key)<br>>>> add(key, val)<br>>>><br>>>> Just seems to plain not work (all adds have zero expiration).
<br>>>><br>>>> If I:<br>>>><br>>>> add(key, val)<br>>>> delete(key, 1)<br>>>> sleep(2)<br>>>> add(key, val)<br>>>><br>>>> It works.<br>>>>
<br>>>> Please can someone enlighten me as to how I may immediately delete<br>>>> a key and then add a key of the same name? I am using<br>>>> memcached-1.1.12 & John McCaskey's mcache extension
1.2.0 beta10.<br>>>><br>>>> I noticed in the archives this thread:<br>>>><br>>>> <<a href="http://lists.danga.com/pipermail/memcached/2004-July/000688.html">http://lists.danga.com/pipermail/memcached/2004-July/000688.html
</a>><br>>>><br>>>> This seems to be related to the problem that I am having but my<br>>>> version of memcached is almost a year later than this so I would<br>>>> assume that the patch referred to in the thread is included. I'm
<br>>>> going to check that this isn't a problem with John's mcache<br>>>> extension but if anyone has a simple answer to my problem I'd love<br>>>> to hear it.<br>>>><br>>>> Thanks a lot for your help :)
<br>>>><br>>>> Matt<br>>>><br>>>><br>>><br>><br>><br>><br>> m a t t h e w g l u b b<br>><br>> ________________________________________________________________________
<br>> Z Group PLC<br>><br>> Tel: +44 (0) 8700 111 173<br>> Fax: +44 (0) 8707 051 393<br>> Txt: +44 (0) 7800 140 877<br>> Web: <<a href="http://www.zgroupplc.com/">http://www.zgroupplc.com/</a>><br>
><br>> PLEASE NOTE ZGROUP IS NOT LIABLE FOR ANY DAMAGES, MALFUNCTION, OR LOSS<br>> OF DATA, CAUSED AS A RESULT OF FOLLOWING ANY ADVICE ENCLOSED IN THIS<br>> EMAIL. ANY CHANGES SHOULD BE CARRIED OUT AT YOUR OWN RISK.
<br>><br>> This email and any files transmitted with it are confidential and<br>> intended solely for the use of the individual or entity to whom they are<br>> addressed. The opinions expressed in this mail are those of the author
<br>> and do not necessarily represent the views of the company. If you have<br>> received this email in error please notify <<a href="mailto:service@zgroupplc.com">service@zgroupplc.com</a>><br>><br>>
<br>><br>><br>><br><br><br><br>------------------------------<br><br>Message: 3<br>Date: Wed, 11 Jan 2006 16:04:04 +0000<br>From: Matthew Glubb <<a href="mailto:matt@zgroupplc.com">matt@zgroupplc.com</a>><br>
Subject: Re: Deletes Are Driving Me Crazy<br>To: Fabian Thylmann <<a href="mailto:fabian@toomuchmedia.com">fabian@toomuchmedia.com</a>><br>Cc: <a href="mailto:memcached@lists.danga.com">memcached@lists.danga.com</a>
<br>Message-ID: <<a href="mailto:ADEC3F04-9F42-48E3-8709-0B3B6525075B@zgroupplc.com">ADEC3F04-9F42-48E3-8709-0B3B6525075B@zgroupplc.com</a>><br>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed<br>
<br>Hi Fabian,<br><br>If you refer to the thread that I quoted in my original mail it was<br>accepted as a bug then and a patch was introduced.<br><br>I am afraid that, for legal reasons, I am unable to provide you with<br>
the specific application of memcache in this instance but I can<br>assure you that I understand that memcache is not a database, it is a<br>cache ;)<br><br>I simply wish to be able to delete a key that has a zero expiry<br>
period and then immediately be able to add a key of the same name.<br>The reason that I cannot use set is because if it already exists in<br>the cache I do not want to replace the value.<br><br>I have just tried the same process with the PECL extension and the
<br>problem persists. For this reason I am pretty sure that the problem<br>is not with the PHP extensions that I have used.<br><br>I should note that this problem seems to be sporadic and time based,<br>leading me to believe that keys are not necessarily deleted from
<br>memcache at the moment the request is made.<br><br>Thanks a lot for your help on this one. Perhaps I have missed<br>something fundamental about memcache regarding deletes, etc?<br><br>Regards,<br><br>Matt<br><br>On 11 Jan 2006, at 15:03, Fabian Thylmann wrote:
<br><br>> Could you explain a little bit more what you are trying to do then?<br>> Maybe you are using memcached in a way it was not designed to be used.<br>><br>> Fabian<br>><br>><br>> Matthew Glubb wrote:
<br>><br>>> Thanks for the reply, but no, that is not want I want. I need to<br>>> know that when I delete an item, it is deleted. I need to be able<br>>> to use add because there are other situations where I want to
<br>>> prevent the possibility of overwriting a value. 'add' is a great<br>>> way to defend against that situation.<br>>><br>>> Matt<br>>><br>>> On 11 Jan 2006, at 11:39, Fabian Thylmann wrote:
<br>>><br>>>> Hi Matt,<br>>>><br>>>> what you probably want is<br>>>><br>>>> set(key, val)<br>>>><br>>>> which will set a new value for key even if it exists.
<br>>>><br>>>> Fabian<br>>>><br>>>><br>>>> Matthew Glubb wrote:<br>>>><br>>>>> Happy New Year to you all.<br>>>>><br>>>>> I am sorry if this has been covered before but I have trawled
<br>>>>> through the list archives and cannot find a definitive solution.<br>>>>><br>>>>> I would really like to know how to:<br>>>>><br>>>>> add(key, val)<br>>>>> delete(key)
<br>>>>> add(key, val)<br>>>>><br>>>>> Just seems to plain not work (all adds have zero expiration).<br>>>>><br>>>>> If I:<br>>>>><br>>>>> add(key, val)
<br>>>>> delete(key, 1)<br>>>>> sleep(2)<br>>>>> add(key, val)<br>>>>><br>>>>> It works.<br>>>>><br>>>>> Please can someone enlighten me as to how I may immediately
<br>>>>> delete a key and then add a key of the same name? I am using<br>>>>> memcached-1.1.12 & John McCaskey's mcache extension 1.2.0 beta10.<br>>>>><br>>>>> I noticed in the archives this thread:
<br>>>>><br>>>>> <<a href="http://lists.danga.com/pipermail/memcached/2004-July/000688.html">http://lists.danga.com/pipermail/memcached/2004-July/000688.html</a>><br>>>>><br>>>>> This seems to be related to the problem that I am having but
<br>>>>> my version of memcached is almost a year later than this so I<br>>>>> would assume that the patch referred to in the thread is<br>>>>> included. I'm going to check that this isn't a problem with
<br>>>>> John's mcache extension but if anyone has a simple answer to<br>>>>> my problem I'd love to hear it.<br>>>>><br>>>>> Thanks a lot for your help :)<br>>>>>
<br>>>>> Matt<br>>>>><br>>>>><br>>>><br>>><br>>><br>>><br>>> m a t t h e w g l u b b<br>>><br>>> _____________________________________________________________________
<br>>> ___<br>>> Z Group PLC<br>>><br>>> Tel: +44 (0) 8700 111 173<br>>> Fax: +44 (0) 8707 051 393<br>>> Txt: +44 (0) 7800 140 877<br>>> Web: <<a href="http://www.zgroupplc.com/">
http://www.zgroupplc.com/</a>><br>>><br>>> PLEASE NOTE ZGROUP IS NOT LIABLE FOR ANY DAMAGES, MALFUNCTION,<br>>> OR LOSS<br>>> OF DATA, CAUSED AS A RESULT OF FOLLOWING ANY ADVICE ENCLOSED<br>
>> IN THIS<br>>> EMAIL. ANY CHANGES SHOULD BE CARRIED OUT AT YOUR OWN RISK.<br>>><br>>> This email and any files transmitted with it are<br>>> confidential and<br>>> intended solely for the use of the individual or entity to whom
<br>>> they are<br>>> addressed. The opinions expressed in this mail are those of the<br>>> author<br>>> and do not necessarily represent the views of the company. If<br>>> you have<br>>> received this email in error please notify <
<a href="mailto:service@zgroupplc.com">service@zgroupplc.com</a>><br>>><br>>><br>>><br>>><br>>><br>><br><br><br><br>m a t t h e w g l u b b<br><br>________________________________________________________________________
<br>Z Group PLC<br><br>Tel: +44 (0) 8700 111 173<br>Fax: +44 (0) 8707 051 393<br>Txt: +44 (0) 7800 140 877<br>Web: <<a href="http://www.zgroupplc.com/">http://www.zgroupplc.com/</a>><br><br>PLEASE NOTE ZGROUP IS NOT LIABLE FOR ANY DAMAGES, MALFUNCTION, OR LOSS
<br>OF DATA, CAUSED AS A RESULT OF FOLLOWING ANY ADVICE ENCLOSED IN THIS<br>EMAIL. ANY CHANGES SHOULD BE CARRIED OUT AT YOUR OWN RISK.<br><br>This email and any files transmitted with it are confidential and<br>
intended solely for the use of the individual or entity to whom they are<br>addressed. The opinions expressed in this mail are those of the author<br>and do not necessarily represent the views of the company. If you have
<br>received this email in error please notify <<a href="mailto:service@zgroupplc.com">service@zgroupplc.com</a>><br><br><br><br><br><br>------------------------------<br><br>Message: 4<br>Date: Wed, 11 Jan 2006 09:24:48 -0800
<br>From: Jeff Rodenburg <<a href="mailto:jeff.rodenburg@gmail.com">jeff.rodenburg@gmail.com</a>><br>Subject: Re: Deletes Are Driving Me Crazy<br>To: Matthew Glubb <<a href="mailto:matt@zgroupplc.com">matt@zgroupplc.com
</a>><br>Cc: <a href="mailto:memcached@lists.danga.com">memcached@lists.danga.com</a><br>Message-ID:<br> <<a href="mailto:50f433360601110924keb90fffya74a7e27bec3cb35@mail.gmail.com">50f433360601110924keb90fffya74a7e27bec3cb35@mail.gmail.com
</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>On 1/11/06, Matthew Glubb <<a href="mailto:matt@zgroupplc.com">matt@zgroupplc.com</a>> wrote:<br>><br>> I simply wish to be able to delete a key that has a zero expiry
<br>> period and then immediately be able to add a key of the same name.<br>> The reason that I cannot use set is because if it already exists in<br>> the cache I do not want to replace the value.<br>><br><br>
I have a somewhat similar requirement, but I'm curious about this specific<br>approach. It sounds as if an object may go into the cache with a given key,<br>but in some scenarios if that key is already in use, that object would use a
<br>different key in the cache. Is that accurate?<br><br>This sound as if you might be using the cache as a queue or something to<br>delineate prioritization or ordering.<br><br>I know this doesn't resolve the particular add/delete/add scenario, but I'm
<br>curious about the requirements side.<br><br>cheers,<br>j<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <a href="http://lists.danga.com/pipermail/memcached/attachments/20060111/811b3acb/attachment.htm">
http://lists.danga.com/pipermail/memcached/attachments/20060111/811b3acb/attachment.htm</a><br><br>------------------------------<br><br>Message: 5<br>Date: Wed, 11 Jan 2006 18:01:02 +0000<br>From: Matthew Glubb <<a href="mailto:matt@zgroupplc.com">
matt@zgroupplc.com</a>><br>Subject: Re: Deletes Are Driving Me Crazy<br>To: Jeff Rodenburg <<a href="mailto:jeff.rodenburg@gmail.com">jeff.rodenburg@gmail.com</a>><br>Cc: <a href="mailto:memcached@lists.danga.com">
memcached@lists.danga.com</a><br>Message-ID: <<a href="mailto:05BB7AE9-E314-4DB1-B0CF-37249FD9C349@zgroupplc.com">05BB7AE9-E314-4DB1-B0CF-37249FD9C349@zgroupplc.com</a>><br>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
<br><br>Okay, I guess I can expand a little :)<br><br>You are right to guess that I am using memcache as a queue of sorts.<br>It's network related.<br><br>Each client has a maximum of N key/value pairs in the memcache.<br>
Multiple, concurrent requests may be arriving from the same client.<br>Every client uses the same key prefix for all of there keys ie.<br>prefix_[0 to N-1]. If a client tries to overwrite one of those key/<br>value pairs once they have been assigned the request is denied, hence
<br>the requirement for using add rather than set. If a client session<br>ends, all N key/value pairs should be deleted. If the same client<br>then starts another session they should be able to recreate up to N<br>key/value pairs using the same key names but containing different
<br>values.<br><br>I have multiple red hat boxes running lighttpd and load-balanced fast-<br>cgi php 5.0.5 modules with John's mcache extension 1.2.0 beta10<br>compiled against libmemcache-1.4.0.b9. Memcached is version 1.1.12
.<br><br>Sometimes it works, sometimes it doesn't. It seems to me that deleted<br>keys are not always deleted 'straightaway'.<br><br>Matt<br><br>On 11 Jan 2006, at 17:24, Jeff Rodenburg wrote:<br><br>> On 1/11/06, Matthew Glubb <
<a href="mailto:matt@zgroupplc.com">matt@zgroupplc.com</a>> wrote:<br>>><br>>> I simply wish to be able to delete a key that has a zero expiry<br>>> period and then immediately be able to add a key of the same name.
<br>>> The reason that I cannot use set is because if it already exists in<br>>> the cache I do not want to replace the value.<br>>><br>><br>> I have a somewhat similar requirement, but I'm curious about this
<br>> specific<br>> approach. It sounds as if an object may go into the cache with a<br>> given key,<br>> but in some scenarios if that key is already in use, that object<br>> would use a<br>> different key in the cache. Is that accurate?
<br>><br>> This sound as if you might be using the cache as a queue or<br>> something to<br>> delineate prioritization or ordering.<br>><br>> I know this doesn't resolve the particular add/delete/add scenario,
<br>> but I'm<br>> curious about the requirements side.<br>><br>> cheers,<br>> j<br><br><br><br>m a t t h e w g l u b b<br><br>________________________________________________________________________<br>Z Group PLC
<br><br>Tel: +44 (0) 8700 111 173<br>Fax: +44 (0) 8707 051 393<br>Txt: +44 (0) 7800 140 877<br>Web: <<a href="http://www.zgroupplc.com/">http://www.zgroupplc.com/</a>><br><br>PLEASE NOTE ZGROUP IS NOT LIABLE FOR ANY DAMAGES, MALFUNCTION, OR LOSS
<br>OF DATA, CAUSED AS A RESULT OF FOLLOWING ANY ADVICE ENCLOSED IN THIS<br>EMAIL. ANY CHANGES SHOULD BE CARRIED OUT AT YOUR OWN RISK.<br><br>This email and any files transmitted with it are confidential and<br>
intended solely for the use of the individual or entity to whom they are<br>addressed. The opinions expressed in this mail are those of the author<br>and do not necessarily represent the views of the company. If you have
<br>received this email in error please notify <<a href="mailto:service@zgroupplc.com">service@zgroupplc.com</a>><br><br><br><br><br><br>------------------------------<br><br>Message: 6<br>Date: Wed, 11 Jan 2006 13:23:53 -0500
<br>From: Greg Whalin <<a href="mailto:gwhalin@meetup.com">gwhalin@meetup.com</a>><br>Subject: Re: Deletes Are Driving Me Crazy<br>To: Matthew Glubb <<a href="mailto:matt@zgroupplc.com">matt@zgroupplc.com</a>>
<br>Cc: <a href="mailto:memcached@lists.danga.com">memcached@lists.danga.com</a><br>Message-ID: <<a href="mailto:43C54D39.3050805@meetup.com">43C54D39.3050805@meetup.com</a>><br>Content-Type: text/plain; charset=UTF-8; format=flowed
<br><br>This sounds like something already brought up in the list some time back.<br><br><a href="http://lists.danga.com/pipermail/memcached/2004-July/thread.html">http://lists.danga.com/pipermail/memcached/2004-July/thread.html
</a><br><br>Check for subj: "Add fails after delete"<br><br>Seems it was supposed to have been fixed?<br><br>gw<br><br>Matthew Glubb wrote:<br>> Okay, I guess I can expand a little :)<br>><br>> You are right to guess that I am using memcache as a queue of sorts.
<br>> It's network related.<br>><br>> Each client has a maximum of N key/value pairs in the memcache.<br>> Multiple, concurrent requests may be arriving from the same client.<br>> Every client uses the same key prefix for all of there keys ie.
<br>> prefix_[0 to N-1]. If a client tries to overwrite one of those key/<br>> value pairs once they have been assigned the request is denied, hence<br>> the requirement for using add rather than set. If a client session
<br>> ends, all N key/value pairs should be deleted. If the same client then<br>> starts another session they should be able to recreate up to N<br>> key/value pairs using the same key names but containing different values.
<br>><br>> I have multiple red hat boxes running lighttpd and load-balanced fast-<br>> cgi php 5.0.5 modules with John's mcache extension 1.2.0 beta10<br>> compiled against libmemcache-1.4.0.b9. Memcached is version
1.1.12.<br>><br>> Sometimes it works, sometimes it doesn't. It seems to me that deleted<br>> keys are not always deleted 'straightaway'.<br>><br>> Matt<br>><br>> On 11 Jan 2006, at 17:24, Jeff Rodenburg wrote:
<br>><br>>> On 1/11/06, Matthew Glubb <<a href="mailto:matt@zgroupplc.com">matt@zgroupplc.com</a>> wrote:<br>>><br>>>><br>>>> I simply wish to be able to delete a key that has a zero expiry
<br>>>> period and then immediately be able to add a key of the same name.<br>>>> The reason that I cannot use set is because if it already exists in<br>>>> the cache I do not want to replace the value.
<br>>>><br>>><br>>> I have a somewhat similar requirement, but I'm curious about this<br>>> specific<br>>> approach. It sounds as if an object may go into the cache with a<br>>> given key,
<br>>> but in some scenarios if that key is already in use, that object<br>>> would use a<br>>> different key in the cache. Is that accurate?<br>>><br>>> This sound as if you might be using the cache as a queue or something to
<br>>> delineate prioritization or ordering.<br>>><br>>> I know this doesn't resolve the particular add/delete/add scenario,<br>>> but I'm<br>>> curious about the requirements side.<br>>>
<br>>> cheers,<br>>> j<br>><br>><br>><br>><br>> m a t t h e w g l u b b<br>><br>> ________________________________________________________________________<br>> Z Group PLC<br>><br>
> Tel: +44 (0) 8700 111 173<br>> Fax: +44 (0) 8707 051 393<br>> Txt: +44 (0) 7800 140 877<br>> Web: <<a href="http://www.zgroupplc.com/">http://www.zgroupplc.com/</a>><br>><br>> PLEASE NOTE ZGROUP IS NOT LIABLE FOR ANY DAMAGES, MALFUNCTION, OR LOSS
<br>> OF DATA, CAUSED AS A RESULT OF FOLLOWING ANY ADVICE ENCLOSED IN THIS<br>> EMAIL. ANY CHANGES SHOULD BE CARRIED OUT AT YOUR OWN RISK.<br>><br>> This email and any files transmitted with it are confidential and
<br>> intended solely for the use of the individual or entity to whom they are<br>> addressed. The opinions expressed in this mail are those of the author<br>> and do not necessarily represent the views of the company. If you have
<br>> received this email in error please notify <<a href="mailto:service@zgroupplc.com">service@zgroupplc.com</a>><br>><br>><br>><br><br><br><br>------------------------------<br><br>_______________________________________________
<br>memcached mailing list<br><a href="mailto:memcached@lists.danga.com">memcached@lists.danga.com</a><br><a href="http://lists.danga.com/mailman/listinfo/memcached">http://lists.danga.com/mailman/listinfo/memcached</a><br>
<br><br>End of memcached Digest, Vol 18, Issue 8<br>****************************************<br></blockquote></div><br>