Memcache CAS

Chris Goffinet goffinet at yahoo-inc.com
Mon Sep 17 07:51:27 UTC 2007


Last time. I attached the wrong diff. This should do it and include  
your change of itmp.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: memcache.cas.drain.diff
Type: application/octet-stream
Size: 6088 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/memcached/attachments/20070917/ecf9a05c/memcache.cas.drain.obj
-------------- next part --------------




Chris Goffinet
goffinet at yahoo-inc.com



On Sep 17, 2007, at 12:44 AM, Chris Goffinet wrote:

> Here is the fix Dustin, I can't believe I missed the code to drain  
> the data line, it was right below :-) Here is the new diff. Its a  
> clean diff from original code to this, and it won't make you  
> maintain 2 versions :)
>
> I will look into the global counter / memory address issue tomorrow  
> and get out a fix.
>
> <memcache.cas.drain.diff>
>
>
>
> Chris Goffinet
> goffinet at yahoo-inc.com
>
>
>
> On Sep 17, 2007, at 12:33 AM, Dustin Sallings wrote:
>
>>
>> On Sep 17, 2007, at 0:31, Chris Goffinet wrote:
>>
>>> 1) Okay. Does it make sense then to just implement a 'revision'  
>>> into the item struct? That way we can just revision++ on new 'set'?
>>
>> 	I think you'd need a global counter.  You wouldn't want a set ->  
>> delete -> set to tell you that your value is the same between those  
>> two sets.
>>
>>> 2) I'll add support for those 3 again so you can see what  
>>> happened. I'll look into draining the output correctly so client's  
>>> won't have an issue with this.
>>
>> 	There's a drain state, but it ends strangely for the text  
>> protocol, I believe.
>>
>> -- 
>> Dustin Sallings
>>
>>
>



More information about the memcached mailing list