[infinispan-dev] CacheStore redesign: no XA cache stores

[Sanne Grinovero]

My experience with transactions is limited, so I likely am missing on
some base concept, but I don't understand why the fact that it's
running on a different process is limiting in any form. We do that
regularly from appservers, queues, RDBMS's, ... ?

In this case the Infinispan node N1 needs to be coordinated by the TM
on N2, and control its "owned" resource C1. I realize that this is
possibly not trivial but somehow I expected that this was implemented
already.. isn't that a component you need for XA anyway? I'm quite
sure Narayana supports this setup as the application server does.

AFAIK a similar design was discussed in 2010 in the Transactions over
Hot Rod design meeting; how would this be fundamentally different, if
that's possible to explain to a non-expert ?


On 30 July 2013 21:20, Mircea Markus <mmarkus at redhat.com> wrote:
> Hi,
>
> I don't think can support XA (JTA) enabled cache stores. Here's why:
> - C1 (cache store instance) runs on node N1
> - an JTA tx is started on N2 which writes to(has a key that maps to) N1 - both to the DataContainer and C1.
> - the JTA transaction manager running the transaction resides on N2, so it's impossible for C1 at N1 (different process) to enlist within that transaction
>
> This limitation doesn't exist for local caches configured with a cache store, but that's rather a particular case.
>
> Our current recovery mechanism supports situations when writing to a cache store fails during commit. If the commit fails, the user is given the opportunity to re-apply transaction's changed and that includes both memory and local storage.
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev