I think this is a great idea Trustin! Do you want to do this through JIRA? On 2010-10-14, at 7:20 AM, 이희승 (Trustin Lee) wrote: > Current BoundedConcurrentHashMap notifies EvictionListener for every > evicted entry. However, as you see from > BoundedConcurrentHashMap.Segment.attemptEviction(..), eviction often > happens in bulk. > > If these evicted entries are supposed to be passivated, it is often > beneficial to begin a transaction because it often takes much less time > to call commit() less often. If N entries are evicted: > > without bulk eviction: > > store.store(e1); -- each store implied a commit() > store.store(..); > store.store(eN); > > with bulk eviction: > > store.begin(mods(e1, ..., eN), tx, true); > > so, what do you think about changing the EvictionListener interface like > this: > > interface EvictionListener<K, V> { > void preEvict(K key); > void postEvict(K key, V value); > > void preBulkEvict(Set<K> keys); > void postBulkEvict(Map<K, V> entries); > } > > abstract class AbstractEvictionListener<K, V> > implements EvictionListener { > void preBulkEvict(Set<K> keys) { > for (K k: keys) { preEvict(k); } > } > void postBulkEvict(Set<K> keys) { > ... > } > } > > I might be missing something though. Please let me know if there is a > way to achieve similar improvement without this modification. > > -- > Trustin Lee - http://gleamynode.net/ > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Vladimir Blagojevic JBoss Clustering Team JBoss, by Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

I think this is a great idea Trustin! Do you want to do this through JIRA?

On 2010-10-14, at 7:20 AM, 이희승 (Trustin Lee) wrote: > Current BoundedConcurrentHashMap notifies EvictionListener for every > evicted entry. However, as you see from > BoundedConcurrentHashMap.Segment.attemptEviction(..), eviction often > happens in bulk. > > If these evicted entries are supposed to be passivated, it is often > beneficial to begin a transaction because it often takes much less time > to call commit() less often. If N entries are evicted: > > without bulk eviction: > > store.store(e1); -- each store implied a commit() > store.store(..); > store.store(eN); > > with bulk eviction: > > store.begin(mods(e1, ..., eN), tx, true); > > so, what do you think about changing the EvictionListener interface like > this: > > interface EvictionListener<K, V> { > void preEvict(K key); > void postEvict(K key, V value); > > void preBulkEvict(Set<K> keys); > void postBulkEvict(Map<K, V> entries); > } > > abstract class AbstractEvictionListener<K, V> > implements EvictionListener { > void preBulkEvict(Set<K> keys) { > for (K k: keys) { preEvict(k); } > } > void postBulkEvict(Set<K> keys) { > ... > } > } > > I might be missing something though. Please let me know if there is a > way to achieve similar improvement without this modification. > > -- > Trustin Lee - http://gleamynode.net/ > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Vladimir Blagojevic JBoss Clustering Team JBoss, by Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Excellent idea. From a user's perspective though, I presume they would still get several callbacks on methods annotated with @CacheEntryEvicted [1] ? Or are you also proposing changing the public API, e.g.: @CacheEntryEvicted -> @CacheEntriesEvicted CacheEntryEvictedEvent [2] -> CacheEntriesEvictedEvent and CacheEntryEvictedEvent.getKey() -> CacheEntriesEvictedEvent.getKeys()? If you are planning on the latter (public API change), I would wait for 5.0. Cheers Manik [1] http://docs.jboss.org/infinispan/4.2/apidocs/org/infinispan/notifications... [2] http://docs.jboss.org/infinispan/4.2/apidocs/org/infinispan/notifications... On 14 Oct 2010, at 12:20, 이희승 (Trustin Lee) wrote: > Current BoundedConcurrentHashMap notifies EvictionListener for every > evicted entry. However, as you see from > BoundedConcurrentHashMap.Segment.attemptEviction(..), eviction often > happens in bulk. > > If these evicted entries are supposed to be passivated, it is often > beneficial to begin a transaction because it often takes much less time > to call commit() less often. If N entries are evicted: > > without bulk eviction: > > store.store(e1); -- each store implied a commit() > store.store(..); > store.store(eN); > > with bulk eviction: > > store.begin(mods(e1, ..., eN), tx, true); > > so, what do you think about changing the EvictionListener interface like > this: > > interface EvictionListener<K, V> { > void preEvict(K key); > void postEvict(K key, V value); > > void preBulkEvict(Set<K> keys); > void postBulkEvict(Map<K, V> entries); > } > > abstract class AbstractEvictionListener<K, V> > implements EvictionListener { > void preBulkEvict(Set<K> keys) { > for (K k: keys) { preEvict(k); } > } > void postBulkEvict(Set<K> keys) { > ... > } > } > > I might be missing something though. Please let me know if there is a > way to achieve similar improvement without this modification. > > -- > Trustin Lee - http://gleamynode.net/ > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev