Somewhat. I'm happy to access the existing EvictionPolicy associated with the region (which is part of the public API of Region, get the EvictionAlgorithm from that (which is part of the public EvictionPolicy API) and invoke process() on that (which is part of the public EvictionAlgorithm API). Looking at the eviction system in JBC, it seems nicely set up to work a la carte: 1) An interceptor that generates events and passes them to the region, which queues them. (This is somewhat coupled to #2 via the EvictionPolicy.canIgnoreEvent() call the interceptor makes.) 2) The EvictionPolicy/Algorithm which can take a process the region's queue of events and determine what to evict, and then evict it. 3) The evict() API on the cache, which is used by EvictionPolicy/Algorithm but also allows self-managed eviction. 4) A thread-management system that kicks off #2. So, main thing is I think JBC should support these combos from the a la carte menu: #1 + #2 + #3 + #4 (of course) #3 #1 + #2 + #3. If configuring this last one requires doing something a bit hacky that's OK by me, although it's better to just be able to say in a config "no #4 please". Again, to me the main thing is to keep those API calls I described above available. [1] I don't see any point in JBC trying to support #1 + #3 (i.e. add a way to bypass the EvictionInterceptor call to EvictionPolicy.canIgnoreEvent()). If someone wants that they can just implement a CacheListener to get events. [1] Probably a good separate discussion is the API of EvictionPolicy/EvictionAlgorithm. Currently those are a bit of a mix of API and SPI, with an implementation detail (delegate to EvictionAlgorithm) mixed in. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164818#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...