[infinispan-dev] Redesigning CacheStore and CacheLoader SPIs

[Sanne Grinovero]

On 2 April 2012 14:31, Tristan Tarrant <ttarrant at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev