[infinispan-dev] keySet(), values() and entrySet() not implemented

Manik Surtani manik at jboss.org
Thu Jun 4 05:44:43 EDT 2009


On 4 Jun 2009, at 10:36, Mircea Markus wrote:

> Galder Zamarreno wrote:
>>
>>
>> Mircea Markus wrote:
>>> Manik Surtani wrote:
>>>> </snip>
>>>>
>>>> I still reckon that these methods should just query the local, in- 
>>>> memory data container.  And be documented such that this is what  
>>>> is expected.  Like I said the potential for OOMs is huge  
>>>> otherwise - regardless of DIST.
>>> that would 'lay' to the user and break the API as well. We can add  
>>> Cache (vs Map) methods for that.
>>
>> Hmmmm, I suppose you mean lie?
> yes :)
>> As long as we document it correctly, I think we should be fine. We  
>> could even show an info message when DIST is in use to further  
>> remain them that the view they get only contains the local data.
>>
>> I don't think it breaks the API. It has limitations but I don't a  
>> break.
> cache.put(k,v);
> asser cache.keySet().contains(k) : "this will fail even within a tx";

This can be a problem with a CHM as well:

map.put(k, v)
assert map.size() // may not return what you expect

> I generally think that it's better not to give any information than  
> give incomplete/incorrect one, on the other hand I see the point  
> with having this local

One of the limitations of Cache extending ConcurrentMap.  IMO the only  
real drawback of extending ConcurrentMap.

>
>> It's a bit like size() with ConcurrentHashMap. It does not give you  
>> an accurate number. The same with keySet()/entrySet() and DIST  
>> mode, it does not give an accurate view because of the pitfalls  
>> mentioned.
>>
>>>> Cheers
>>>> -- 
>>>> Manik Surtani
>>>> manik at jboss.org
>>>> Lead, Infinispan
>>>> Lead, JBoss Cache
>>>> http://www.infinispan.org
>>>> http://www.jbosscache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

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







More information about the infinispan-dev mailing list