[infinispan-dev] HotRod?? [ISPN-29 and a "custom protocol"]

[Galder Zamarreno]

On 12/10/2009 04:35 PM, Manik Surtani wrote:
>
> On 10 Dec 2009, at 15:24, Galder Zamarreno wrote:
>
>>
>>
>> On 12/10/2009 03:15 PM, Manik Surtani wrote:
>>>
>>> On 10 Dec 2009, at 12:23, Galder Zamarreno wrote:
>>>>>> Also, it might be wised to implement operations like replaceIfEquals
>>>>>> using with a cas long, like memcached does
>>>>>> (http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol), rather
>>>>>> than sending the value cos that would be more network efficient. The old
>>>>>> value could be much more longer.
>>>>>
>>>>> Not sure I understand.  So we have 2 replace methods (thanks to ConcurrentMap) - replace(k, v) which succeeds if k is mapped to something, and replace(k, v1, v2) which succeeds if k is mapped to v1.  From what I see, only the former is supported by memcached's binary protocol and not the latter.  Are you suggesting supporting the latter in HotRod?
>>>>
>>>> I'm suggesting supporting both actually.
>>>>
>>>> replace(k, v) which succeeds if k is mapped to something - that's the
>>>> same as memcached's replace command. I plan to support that.
>>>>
>>>> replace(k, v1, v2) is what memcached does with 'cas' but instead of
>>>> passing the old value, it passes the cas id, which is 8 bytes at the
>>>> most. The old value could be a lot longer. In ConcurrentMap, replace
>>>> works by passing the old value.
>>>
>>> Sure, and that's in the same VM so you pass by reference.  Across the wire, this may involve serializing the entire (old) value which may be quite large.
>>>
>>>> I think, to save network space, I think we should implement it the way
>>>> memcached does. IOW, whenever something gets stored, it's stored with a
>>>> cas id and this can later be used to replace a value, only of the cas is
>>>> the one as we've passed.
>>>
>>> You get this cas id back as a return value?  Which you can then store and use in future 'replace' commands?  Is this it?
>>
>> Yeah, u can get the cas id via gets command.
>>
>>>
>>>> In the txt protocol, I implemented the cas id using System.nanoTime().
>>>
>>> Is this cas id meant to be unique?  If so, System.nanoTime() may not be ...
>>
>> Not over time. You want to be unique from the minute you retrieved it
>> until you use it and for operations on that particular key.
>>
>> The cas Id is simply used for comparison, to check whether someone else
>> has changed the entry since you retrieved it. System.nanoTime() gives
>> you precisely that, anyone that modifies that entry in that machine will
>> definitely have a different nano time. Also, since nano time is based
>> off an arbitrary time, the chances that a different machine will produce
>> the same nano time when modifying that very same key are almost very
>> very small.
>
> Improbable but certainly not impossible, even in 1 machine.
>
> Why not just use what we use for 'versioning' internally - object references?  System.identityHashCode(), for example?

Remember that you have to deal with eviction/expiration too. You could 
get a case like this:
- get a cas based on identity hash code
- the entry is expired
- a new entry is put, with diff values, which happens to have the same 
identify hash code.
- doing a cas will succeed when it shouldn't.

I don't think this can happen with System.nanoTime().

When looking into this, I checked java.util.UUID but it didn't work, for 
at least for the memcached txt protocol, where a 64bit value is required 
and UUID is 128bits. Maybe we could try to compress it somehow?


>
> Cheers
> --
> 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