Re: [infinispan-dev] CacheLoader and CacheStore
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>
----- Original Message -----
From: "Mircea Markus" <mmarkus(a)redhat.com>
To: "infinispan -Dev List" <infinispan-dev(a)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.
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/cach...
[2]
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cach...
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