Hi Brian, Of my original email, there's a section that I don't think has been answered yet On 08/04/2009 10:37 AM, Galder Zamarreno wrote: > Finally, a question to the list, specially for Brian/Steve who worked on > the JBC2/3 integration layer: > > - Do we need a similar timestamp region local cache implementation for > an ISPN based cache provider? This question focuses on the TimestampsRegionImpl (and potentially ClusteredConcurrentTimestampsRegionImpl) work done for JBC 2.x/3.x integration layer. Is there a need for a similar region implementation for Infinispan? I'm not sure I fully understand the need for TimestampsRegionImpl to manage this local cache. Talking about timestamps, I assume that no evictions should ever happen for the timestamps cache and this is something that could be validated on startup, that eviction strategy is NONE.

Cheers,

On 08/13/2009 06:27 AM, Galder Zamarreno wrote: > Hi Brian, > > Of my original email, there's a section that I don't think has been > answered yet > > On 08/04/2009 10:37 AM, Galder Zamarreno wrote: >> Finally, a question to the list, specially for Brian/Steve who worked on >> the JBC2/3 integration layer: >> >> - Do we need a similar timestamp region local cache implementation for >> an ISPN based cache provider? >> >> Cheers, > > This question focuses on the TimestampsRegionImpl (and potentially > ClusteredConcurrentTimestampsRegionImpl) work done for JBC 2.x/3.x > integration layer. Is there a need for a similar region implementation > for Infinispan? I'm not sure I fully understand the need for > TimestampsRegionImpl to manage this local cache. > Timestamps caching has different semantics than the other types, hence the different region impl. I don't know any reason why that wouldn't be the case with Infinispan. It's not a "local cache"? It's replicated.

> Talking about timestamps, I assume that no evictions should ever happen > for the timestamps cache and this is something that could be validated > on startup, that eviction strategy is NONE. > +1. > Cheers,