Hi, Starting from the original document Manik rolled out a while ago [1], here's the list of requirements I'm currently aware of in the context of the new CacheStore API: - better integration with the fluent API (CacheStore.init() is horrendous) - support for non-distributed transaction cache stores (1PC) and support for XA capable cache store - support iteration over all the keys/entries in the store - needed for efficient Map/Reduce integration - needed for efficient implementation of Cache.keySet(), Cache.entrySet(), Cache.values() methods - a simple read(k) + write(k,v) interface to be implemented by users that just want to position ISPN as a cache between an app and a legacy system and which don't need/want to be bothered with all the other complex features - support for expiration notification (ISPN-3064) - support for size (efficient implementation of the cache.size() method) Re: JSR-107 integration, I don't think we should depend on the JSR-107 API as it forces us to use JSR-107 internal structures[2] but we should at least provide an adapter layer.

[1] https://community.jboss.org/wiki/CacheLoaderAndCacheStoreSPIRedesign [2] https://github.com/jsr107/jsr107spec/blob/v0.8/src/main/java/javax/cache/... Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 24 Jul 2013, at 16:42, Galder Zamarreño <galder(a)redhat.com&gt; wrote: >> Hi, >> >> Starting from the original document Manik rolled out a while ago [1], here's the list of requirements I'm currently aware of in the context of the new CacheStore API: >> - better integration with the fluent API (CacheStore.init() is horrendous) >> - support for non-distributed transaction cache stores (1PC) and support for XA capable cache store >> - support iteration over all the keys/entries in the store >> - needed for efficient Map/Reduce integration >> - needed for efficient implementation of Cache.keySet(), Cache.entrySet(), Cache.values() methods >> - a simple read(k) + write(k,v) interface to be implemented by users that just want to position ISPN as a cache between an app and a legacy system and which don't need/want to be bothered with all the other complex features >> - support for expiration notification (ISPN-3064) >> - support for size (efficient implementation of the cache.size() method) >> >> Re: JSR-107 integration, I don't think we should depend on the JSR-107 API as it forces us to use JSR-107 internal structures[2] but we should at least provide an adapter layer. > > I agree on not depending on it, but design it in such way that's easy to write such adapter. IOW, make sure the functionality in the JSR-107 API is covered easily, without having add boiler-plate code :) +1 Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 24 Jul 2013, at 17:16, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: > Also: > - support to efficiently preload only the owned entries We'd still need to iterate over all the stored keys to decide which maps to the local node, but we won't have to load the entries. Is that what you have in mind?

> - expiry of entries without loading them in memory This is something we do already with CacheStore.purgeExpired

> - pass one (or more) existing CacheStore instance(s) into a starting > CacheManager to be used Something to consider but out of the scope of this change. > New one, after recent talking to myself :-) : > - Allow the CacheStore instance to get a reference to the Cache > itself: I need to perform a get() operation from the CacheStore to > implement "write behind" to a relational database, in case you have > mapped entities -> OGM -> Infinispan -> ORM -> relational database and > want to respect the original mapping. > Otherwise entries might be incomplete, or get written in the wrong > order, violating referential integrity rules. The CacheLoader.init(..) method does this already, I'll make sure it doesn't go away in this release :-)

> > In other words, just allow me to inject a reference to the > CacheManager in the CacheStore instance. > Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

- support to efficiently preload only the owned entries

State transfer currently needs to retrieve from cache store just certain CH segments but this is not directly possible with current API so we have to iterate over the entire set. Would it make sense to add retrieval methods that allow a segment or set of segments to be specified? Adrian On 07/24/2013 01:55 PM, Mircea Markus wrote: > Hi, > > Starting from the original document Manik rolled out a while ago [1], here's the list of requirements I'm currently aware of in the context of the new CacheStore API: > - better integration with the fluent API (CacheStore.init() is horrendous) > - support for non-distributed transaction cache stores (1PC) and support for XA capable cache store > - support iteration over all the keys/entries in the store > - needed for efficient Map/Reduce integration > - needed for efficient implementation of Cache.keySet(), Cache.entrySet(), Cache.values() methods > - a simple read(k) + write(k,v) interface to be implemented by users that just want to position ISPN as a cache between an app and a legacy system and which don't need/want to be bothered with all the other complex features > - support for expiration notification (ISPN-3064) > - support for size (efficient implementation of the cache.size() method) > > Re: JSR-107 integration, I don't think we should depend on the JSR-107 API as it forces us to use JSR-107 internal structures[2] but we should at least provide an adapter layer. > > [1] https://community.jboss.org/wiki/CacheLoaderAndCacheStoreSPIRedesign > [2] https://github.com/jsr107/jsr107spec/blob/v0.8/src/main/java/javax/cache/... > > Cheers, _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Hi, Starting from the original document Manik rolled out a while ago [1], here's the list of requirements I'm currently aware of in the context of the new CacheStore API: - better integration with the fluent API (CacheStore.init() is horrendous) - support for non-distributed transaction cache stores (1PC) and support for XA capable cache store - support iteration over all the keys/entries in the store - needed for efficient Map/Reduce integration - needed for efficient implementation of Cache.keySet(), Cache.entrySet(), Cache.values() methods - a simple read(k) + write(k,v) interface to be implemented by users that just want to position ISPN as a cache between an app and a legacy system and which don't need/want to be bothered with all the other complex features - support for expiration notification (ISPN-3064) - support for size (efficient implementation of the cache.size() method) Re: JSR-107 integration, I don't think we should depend on the JSR-107 API as it forces us to use JSR-107 internal structures[2] but we should at least provide an adapter layer. [1] https://community.jboss.org/wiki/CacheLoaderAndCacheStoreSPIRedesign [2] https://github.com/jsr107/jsr107spec/blob/v0.8/src/main/java/javax/cache/... Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org)