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(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder ZamarreƱo
Sr. Software Engineer
Infinispan, JBoss Cache