[infinispan-dev] New API to iterate over current entries in cache

[Radim Vansa]

Why listeners are not invoked? JCache iterator() notifies the listeners.

Can the iterator remove entries?

I assume there's no ordering guarantee, but behaviour under concurrent 
changes would be rather tricky. I don't like the idea of iterating over 
changing structure.

If you need to iterate through all entries, I'd rather introduce the 
snapshot ability and then iterate over the snapshot. Then, you wouldn't 
have to mess with tx and introduce non-tx operation on tx cache.

My 2c

Radim

On 03/17/2014 02:30 PM, William Burns wrote:
> While working on ISPN-4068 to add the current state to listeners that
> were added I found that what I essentially needed was a way to iterate
> over the entries of the cache.  I am thinking of adding this to the
> public API available on the AdvancedCache interface.
>
> I wanted to get your guy's opinions if you don't think we should add
> it or any changes you might suggest.
>
> My thought was to add 2 overloaded methods:
>
> <C> Iterator<Map.Entry<K, C>> entryIterator(KeyValueFilter<? super K,
> ? super V> filter, Converter<? super K, ? super V, C> converter);
>
> and
>
> Iterator<Map.Entry<K, V>> entryIterator(KeyValueFilter<? super K, ?
> super V> filter);
>
> The method would return almost immediately after invocation and the
> iterator would queue entries and block as entries are required to be
> returned.  The filter and converter are applied on each of the remote
> nodes and are required to be serializable or have an externalizer
> registered.
>
> Internally the iterator would use chunking to help prevent memory
> saturation.  The max memory usage would be (chunkSize * N) + local
> entries where N is the number of nodes.
>
> These methods would be different than other methods on the
> Cache/AdvancedCache in the following things:
>
> 1. This operation is treated as nontx and thus won't store them into
> the context and thus repeatable read semantics would not be
> guaranteed.  This doesn't preclude manually adding values to the
> context.  Also prior writes in the current context would be ignored
> (current data returned), although this could be changed if desired.
> 2. Values are not activated from loaders and visited listeners would
> not be notified of access.  The latter could be sensibly changed if
> desired.
>
>   - Will
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA