[infinispan-dev] CacheLoader and CacheStore

Tue Aug 13 10:30:21 EDT 2013

On Aug 13, 2013, at 12:20 PM, Mircea Markus <mmarkus at redhat.com> wrote:

> On 13 Aug 2013, at 07:59, Galder Zamarreño <galder at redhat.com> wrote:
> 
>> My preference is for #1. 
>> 
>> The main reason is cos JSR-107 is about to hit mainstream and we should try to align with it in a way that we reduce confusion. Remember that JSR-107 users are potential Infinispan users, and viceversa, so keeping these interfaces separated would make the mental effort required to bridge the knowledge between the two easier.
>> 
>> I tried to go back in the JSR-107 discussions to find discussions (google group) on this topic but couldn't find anything. Maybe Manik remembers something about it, but seems like this topic has been pretty much set in stone for quite a while.
>> 
>> In terms of configuration, there's no issue at all. Each cache store provides its own schema now.
> 
> 
> good point. Not the custom ones though, these still need a custom tag.

^ No, we don't, or if we currently do, we shouldn't stop doing so. 

IOW, even those who want to create a custom cache store should follow the same pattern of providing their own XML schema parser for their config, configuration builder files…etc. That gets rid of the problem altogether, and by checking the type of the cache loader/store, we can figure out whether it's read-only, write-only or read-write (assuming we keep the interfaces separated).

Cheers,

> 
>> We're moving away from <loader class="x"> format. With this in mind, given a xxxStore, Infinispan can look at the xxxStore type, cache loader or writer, or both, we can inherently determine whether it's a read-only cache store, a write-only one or both. 
>> 
>> Cheers,
>> 
>> On Aug 10, 2013, at 2:22 AM, Mircea Markus <mmarkus at redhat.com> wrote:
>> 
>>> 
>>> On 9 Aug 2013, at 23:49, Manik Surtani <msurtani at redhat.com> wrote:
>>> 
>>>> My vote is #1.
>>>> 
>>>> To get around the cf issue, how about we do something like have a tag that exposes the functionality, not the type implemented?  E.g.:
>>>> 
>>>> <persistence class="" readOnly="" shared="" ... >
>>>> </persistence>
>>> 
>>> It's indeed solvable, but it adds the "persistence" layer of indirection :-)
>> 
>> ^ Guys, we've been moving away from this type configuration as shown in [6]. We now have per-cache store configuration where each cache store provides its own scheme. This is way better than the old loader+class configuration…
>> 
>> [6] https://docs.jboss.org/author/display/ISPN/Cache+Loaders+and+Stores#CacheLoadersandStores-Filesystembasedcacheloaders
>> 
>>> Most of the users need read/write operations. So they'd implement a Loader and a Writer and then configure it as a Persistence. (#1)
>>> Or they can implement a Loader and configure it as a Loader (#2) ;)
>>> 
>>> 
>>>> 
>>>> ----- Original Message -----
>>>> From: "Mircea Markus" <mmarkus at redhat.com>
>>>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>>>> Sent: Friday, 9 August, 2013 7:21:14 PM
>>>> Subject: [infinispan-dev] CacheLoader and CacheStore
>>>> 
>>>> Hi,
>>>> 
>>>> Apologies for the long email :-)
>>>> 
>>>> There have been several discussions around how the CacheStore and CacheLoader functionality should look in the new CacheLoader API.
>>>> Here's are the possible approaches:
>>>> 
>>>> 1. Have CacheLoader and CacheWriter as independent interfaces, the way JSR 107 does it ([1][2]). Note that CacheWriter does not extend CacheLoader.
>>>> Pros:
>>>> a. [major] follows the  JSR-107 standard, in future people might be used to this way of implementing stuff
>>>> b. [minor] a cleaner design: people can only implement a CacheLoader if all they do is load data
>>>> Cons:
>>>> c. tricky to configure in XML: we use the "loader" tag for configuring a CacheLoader. A "writer" (or "store" as we do now) tag for configuring a CacheWriter. But what are we going to use in order to configure something that implements both CacheLoader and CacheWriter? "writer" as we do now? or allow both? or require one to configure the same entity both as a "loader" and as a "writer"? The later would make the most sense but I think would result in a configuration nightmare. 
>> 
> 
> 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

--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org