Re: [infinispan-dev] [ISPN-116] Async cache store: aggregation of multiple changes on a single key

Hi, Re: https://jira.jboss.org/jira/browse/ISPN-116 I can see two ways of providing such feature: 1. Rather than using a queue, using a data structure similar to the one used in the data container so that when a newer value for a key already present in the queue is present, the value can be swapped (map like lookup required on the key so that O(1) is maintained) while maintaining queue-like FIFO operations required to empty it. 2. Based on suggestion coming amin59 in http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240980#..., make the current queue only store keys and make the draining process query the cache for the latest value. Because from the time the data was put to the cache to the time it's stored, the data could have expired or had been removed all together, such query would need to make sure it doesn't go to the cache loader again. Also, if the data had been removed, how would the Async store know that from cache.get()? The queue would need to record somehow that a key was actually removed. The benefit of the 1st option is that we can take advantage of fast drainTo() like operations when draining it, and also the fact that no contention is added to the cache itself. The downside would be the need for a more complex data structure. The benefit of the 2nd option is the keeping a simple queue, less complex data structure, but requires that each time a key is to be drained, we have to query the cache. This could slow down the draining process. My preference is with 1. but for to use it, I'd need the data container collection to be made more generic. Thoughts? -- 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