Re: [infinispan-dev] CacheStore redesign: no XA cache stores
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(a)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@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev