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 <> 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 (
> _______________________________________________
> infinispan-dev mailing list
infinispan-dev mailing list

Reply via email to