[infinispan-dev] CacheLoader and CacheStore

Dennis Reed dereed at redhat.com
Fri Aug 9 17:28:41 EDT 2013


My vote is #2, as it simplifies the code and removes redundant code 
(fewer chances for bugs).

We've already had to fix one bug where the code reading the cache loader 
configuration was different than reading the cache store configuration.

-Dennis

On 08/09/2013 01:21 PM, Mircea Markus wrote:
> 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.
>    d. The terms "cache loader" and "cache store" are used interchangeably which causes confusion through the users.
>
> 2. Have a sigle interface that exposes the all the methods from CacheLoader and CacheWriter. (Name it CacheLoader?)
> Pros:
>    a. [major] clear and simple configuration. avoid confusion throughout the users
>    b. [minor] most of the API implementors implement both loaders and stores. They'd only have to deal with a single SPI interface for this
> Cons:
>    c. doesn't follow exactly JSR-107's way of doing things.
>    d. people that only need to load data would need to leave the store methods empty. Not as nice as having a specific interface for it.
>     
> 3. Stick to the current approach of having CacheWriter extends CacheLoader
> Pros:
>    a. [minor] a cleaner design: people can only implement a CacheLoader if all they do is load data
>    b. [minor] clear configuration. we'd use "loader" and "writer" tags (as we do now)
> Cons:
>    c. The terms "cache loader" and "cache store" are used interchangeably which causes confusion through the users
>
> My personal preference is for 2 because of simplicity.
> Opinions?
>
> [1] https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/integration/CacheLoader.java
> [2] https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/integration/CacheWritter.java
>
> Cheers,



More information about the infinispan-dev mailing list