[infinispan-dev] Hotrod - removeIfUnmodified request
Galder Zamarreno
galder at redhat.com
Fri Mar 26 12:07:57 EDT 2010
On Fri, 26 Mar 2010 14:35:38 +0100, Sanne Grinovero
<sanne.grinovero at gmail.com> wrote:
> I think the value is needed :)
> How would this be an atomic operation otherwise?
> This is matching the semantics of
> boolean java.util.concurrent.ConcurrentMap.remove(Object key, Object
> VALUE)
>
> right?
That's what entry version is for. In a client/server arch, comparing the
value itself is not very efficient. Imagine having to doing a
removeIfUnmodified with a 10MB entry. Instead, we use versions. Each time
a key is modified, the value gets a new version. Clients can retrieve the
version and then pass it to the server to verify whether anyone else
modified it. When doing suhc operations within VM, you can just pass the
object cos you pass it by reference. THere's no waste of resources there.
>
> 2010/3/26 Galder Zamarreno <galder at redhat.com>:
>> Wiki updated: https://community.jboss.org/wiki/HotRodProtocol
>>
>> On Fri, 26 Mar 2010 13:50:21 +0100, Galder Zamarreno <galder at redhat.com>
>> wrote:
>>
>>> Not only that, the value part does not make sense either since it's a
>>> removal :). The entry version and key are enough.
>>>
>>> Thanks Mircea!!
>>>
>>> On Fri, 26 Mar 2010 11:43:04 +0100, Galder Zamarreno
>>> <galder at redhat.com>
>>> wrote:
>>>
>>>> Indeed, well spotted Mircea. I'll update the wiki right away.
>>>>
>>>> On Fri, 26 Mar 2010 09:56:17 +0100, Manik Surtani <manik at jboss.org>
>>>> wrote:
>>>>
>>>>> Well spotted. Remove has no use for these 2 params.
>>>>>
>>>>> On 26 Mar 2010, at 08:18, Mircea Markus wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> At the moment, removeIfUnmodified looks like follows: [header][key
>>>>>> length][key][lifespan][max idle][entry_version][value length][value]
>>>>>> Does it make sense to also send maxidle and lifespan for a remove
>>>>>> operation?
>>>>>>
>>>>>> Cheers,
>>>>>> Mircea
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> infinispan-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>> --
>>>>> Manik Surtani
>>>>> manik at jboss.org
>>>>> Lead, Infinispan
>>>>> Lead, JBoss Cache
>>>>> http://www.infinispan.org
>>>>> http://www.jbosscache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> 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
>
> _______________________________________________
> 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
More information about the infinispan-dev
mailing list