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