[infinispan-dev] requirements for the new CacheStore API

[Sanne Grinovero]

Also:
 - support to efficiently preload only the owned entries
 - expiry of entries without loading them in memory
 - pass one (or more) existing CacheStore instance(s) into a starting
CacheManager to be used

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.

In other words, just allow me to inject a reference to the
CacheManager in the CacheStore instance.

On 24 July 2013 16:45, Mircea Markus <mmarkus at redhat.com> wrote:
>
> On 24 Jul 2013, at 16:42, Galder Zamarreño <galder at redhat.com> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev