Memcache CAS

[Chris Goffinet]

1) For :1113 I noticed if I added the item_remove diff like you  
suggested, it ends up returning the memory identifier of the new  
variable that is always the same in memory vs address of actual item  
pulled from item_get. Suggestions to fix? Try it yourself, when you  
use the same itmp variable on it and set a few items over and over  
again. It will usually always be same memory address (even if data  
changes).

2) Yeah I expanded item_alloc because the way memcache reads through  
the loop of data sent. Originally I did it the way I sent you, but ran  
into an issue with existing clients. I noticed that memcached would  
throw an error right when memcache read the cas command (which is  
OK..). But all of our commands (add,replace,set) wait until  
complete_nread occur before returning either STORED/NOT_STORED to be  
compatible with existing clients.

I have no problems reverting back to the original method if you might  
have a solution for that?


Chris Goffinet
goffinet at yahoo-inc.com



On Sep 16, 2007, at 11:41 PM, Dustin Sallings wrote:

>
> On Sep 16, 2007, at 22:25, Chris Goffinet wrote:
>
>> Sorry for getting this in late, here is the memcache cas patchset I  
>> did with the help of Dustin Sallings. I'll try to get the pecl  
>> memcache diff out too later this week, just super busy right now.  
>> It's prototype, but works and I know can be cleaned up :-) If I get  
>> time I'll do that too.
>
> 	Couple of comments on this version:
>
> 	1)  You've got an item_get that doesn't have a corresponding  
> item_remove (:1113)
> 	2)  I don't completely understand why item was expanded for an  
> identifier.  Its usage seems to suggest it's a parameter being  
> passed into store.
> 	3)  Can no longer distinguish between a missing record (need to  
> add) or a missed identifier (need to refetch and try again).
>
> 	Both #2 and #3 seem to have something to do with the new parameter  
> on item_alloc.  Is it possible to avoid this API change?  It's not a  
> *huge* deal, but it causes a forward compatibility issue with my  
> binary patches on my single patch stack.  If you could avoid the API  
> change, I wouldn't have to maintain two different versions.  :)
>
> -- 
> Dustin Sallings
>
>