[infinispan-dev] More thoughts on HotRod's ForceReturnPreviousValue

[Mircea Markus]

Sorry for the late answer.
I think It's simple for the client code to keep track of it the sent flags, as it currently happens.

On 30 Mar 2010, at 19:05, Galder Zamarreno wrote:

> See below:
> 
> On Mon, 29 Mar 2010 13:47:59 +0200, Manik Surtani <manik at jboss.org> wrote:
> 
>> 
>> On 26 Mar 2010, at 17:03, Galder Zamarreno wrote:
>> 
>>> Hi all,
>>> 
>>> I've been thinking further about ForceReturnPreviousValue flag in
>>> http://community.jboss.org/wiki/HotRodProtocol.
>>> 
>>> Currently, if no ForceReturnPreviousValue is passed, the responses for
>>> put, putIfAbsent, replace, replaceIfUmodified, remove and
>>> removeIfUmodified looks like this:
>>> 
>>> [header]
>>> 
>>> Now, if ForceReturnPreviousValue is passed, the idea is this: If
>>> ForceReturnPreviousValue has been passed, responses will contain  
>>> previous
>>> [value length][value] for that key. If the key does not exist or  
>>> previous
>>> was null, value length would be 0. Otherwise, if no
>>> ForceReturnPreviousValue was sent, the response would be empty.
>>> 
>>> However, as it is, this means that for a put, the response would be
>>> either, [header] or [header][value lenght][value]. So, in effect, the
>>> client decoder needs to know about the request itself to be able to
>>> determine whether it needs to read the value length or not. I wonder
>>> whether this could be imposing some restrictions on the client decoder.
>>> So, instead, I was wondering whether this might make more sense and make
>>> implementation of the client decoder easier.
>>> 
>>> put, putIfAbsent, replace, replaceIfUmodified, remove and
>>> removeIfUmodified responses looks like this:
>>> [header][value length]
>>> 
>>> *If no ForceReturnPreviousValue is sent, value length will always be 0*.
>>> If ForceReturnPreviousValue is passed and key was not present, or  
>>> previous
>>> value was null, value length is 0. Otherwise, value length will be non
>>> zero and value will follow.
>>> 
>>> The idea here is that these ops responses always return a value length,
>>> regardless of whether the flag is present or not. This, I think, would
>>> make client dcoders easier since they always know what they need to read
>>> and can pass it back without knowing which flags were passed on the
>>> request.
>>> 
>>> Thoughts?
>> 
>> Don't clients hold on to the message id when a message is sent, and  
>> shouldn't the response contain the same message id?  That should allow  
>> clients to decide whether to parse a return value or not.
> 
> Indeed they can do that.
> 
> I just thought having it always there would make decoding easier since  
> they can decode without needing to know about the request. After decoding,  
> you do need to match up the response accordingly and send it back to the  
> client. I've ended up implementing this as originally thought though.
> 
>> 
>> --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> 
> -- 
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev