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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev