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