[infinispan-dev] Redesigning CacheStore and CacheLoader SPIs

[Sanne Grinovero]

On 2 April 2012 14:57, Mircea Markus <mircea.markus at jboss.com> wrote:
>
> On 2 Apr 2012, at 14:45, Sanne Grinovero wrote:
>
>> 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.
> the cache store is an extension of ISPN's internal storage, so if it isn't JTA compliant then ISPN configured with a cache store, as a whole, is not JTA compliant.
>
>>
>> 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.
> That depends on your consistency requirement. If you require (JTA) transactions then write behind simply doesn't give you the consistency guarantees you're after.  You could indeed write in the store and cache directly from user code and then check the cache but we already do this for you :-)
>
>>
>> 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)
> - not sure we can create a generic enough JDBC cache store that would map to any schema, I think custom impls are the way to go here.

Sure, but even then if you try implementing a custom one it's not easy
as you might need some more context or be able to remote-get more keys
than what you are being passed; a problem I had is the CacheLoader is
not able to load additional keys it might need to assemble some
complex structure which is stored as multiple entries, especially if
the CacheLoader is not shared, as the needed key might not be
available in the store itself.

>> - doesn't have a "remove expired" function, needs to load all values
>> to check them
> - that's cache store specific.
>> - no way to list all keys without loading the values
>> - totally no support for MVCC
> - not sure what you mean by that.. better support for storing the version perhaps?

Yes, I think we'll need them; didn't think it much through, but
operations like "purge values before version", or load(key, version),
etc..
In database terms, storing the version at all would be a good start.

>>
>> 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
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev