On 2 Apr 2012, at 15:06, Manik Surtani wrote:
On 2 Apr 2012, at 14:57, Mircea Markus wrote:
>
> On 2 Apr 2012, at 14:45, Sanne Grinovero wrote:
>
>> 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.
> 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.
Not true. If Infinispan acts as a JTA proxy (which is what it currently does), then it
still is JTA compliant.
Not sure what you mean by JTA proxy? ISPN is a fully flagged
XAResource, but when you use a non-JTA cache store inconsistencies can occur ( not aCid
transactions).