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

[Manik Surtani]

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.

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org