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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA