Well, listeners and events were designed independent to AHMs. And hence the weird
behaviour when the two collide.
I think, from a 5.1.3 perspective, we should document that the values passed in to
listeners when using AHMs and the TreeCache will be unreliable. And then we need to think
about what this should ideally look like before attempting a fix.
On 27 Mar 2012, at 12:11, Galder ZamarreƱo wrote:
Hi all,
Re:
https://issues.jboss.org/browse/ISPN-1935
I don't see an easy solution for this. See test in
https://github.com/galderz/infinispan/blob/t_1935_m/tree/src/test/java/or...
The problem is the cache.put() from where the cache entry modified event is thrown comes
from when the AtomicHashMap is created, which at that point is empty.
Once the AHM is created, we then modify the map which does not generate any events, it
just generates the deltas.
Finally, when the operation is completed, a prepare replicates the actual deltas in the
cluster (not in the test, but in a clustered test).
But a user can't listen for @TransactionCompleted and expect to see the list of
modifications.
Any other ideas?
Cheers,
--
Galder ZamarreƱo
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org