Re: [infinispan-dev] Redesigning CacheStore and CacheLoader SPIs
On 2 April 2012 14:31, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
On 04/02/2012 03:17 PM, Mircea Markus wrote:
> On 2 Apr 2012, at 14:02, Tristan Tarrant wrote:
>
>> I dislike the current way of configuring stores via<property>. As part of
my work for ISPN-1821 I will also introduce the ability for stores to provide their own
configuration parsers so that we can have more readable schemas.
> That would be quite nice, as the property-based approach is very error prone. Curious
how you're going to support 'dynamic' xml snippets,through some xml name
spaces perhaps?
Yes, just like the Spring configuration or even the AS7 configuration
itself. In XSD speak they would be complex-types extending a generic
"store" type.
+1, same for the Query options: <properties /> is limiting.
>> Participating in JTA is obviously high on the desired list,
and I'd also expose some form of batching so that intelligent cache-store can colaesce
operations together for better performance.
> that's a big one indeed. JTA support won't be available for all stores, e.g.
cloud cache store.
I think very few stores would have the ability to participate in JTA,
but if a cache store can, we should definitely support it.
Why "definitely" ? It's of course nice to have, but I'm not sure of
the actual value.
If we're planning to include a guarantee of storage in the cacheloader
before the cache operation returns, that means the cacheloader can't
be configured as write-behind, correct?
Now if the CacheLoader is not in write-behind, and it's a different
resource than the Cache itself, I see not much value in it since I
could write in both the cache and the cacheloader from user code
directly, if I needed this functionality.
as I see it, the biggest values of a CacheLoader are:
- to have the cache load from it
- write-behind with coaleshing and batching
which don't sound like it needs to participate in the same transaction
as the Cache operations. It could still use transaction to sync cache
and CacheLoader, but that's possible without changing the interface.
And the current limitations:
- it' s hard to have it "translate" from - taking JDBC for example -
an existing schema. (Or - for example - store the Lucene index in it's
native format on disk)
- doesn't have a "remove expired" function, needs to load all values
to check them
- no way to list all keys without loading the values
- totally no support for MVCC
Imho these are more usefull, unless I'm totally missing what's the
intention of JTA participation ?
> Mind detailing a bit on the batching/colaesce functionality you
have in mind?
Actually I wasn't thinking about anything more complex than what we have
already with the applyModifications() call (which in fact could be
reused), but my understanding is that this is only called in
transactional cache operations ? For example the AsyncStore applies
lists modifications internally, without delegating to the cachestore's
implementation.
Tristan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev