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

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 31 July 2013 16:01, Mircea Markus <mmarkus(a)redhat.com&gt; wrote: > > On 30 Jul 2013, at 23:12, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: > >> 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, ... ? > > It's limiting in the sense that we would have to build an XAResource bridge on the node where the tx manager runs that delegates/bridges xa instructions received from the transaction manager as RPCs to the xa cache store residing on the remote node(s). This is a rather complicated approach and might involve all the bridging RPCs to be sent in sequence which would hurt the performance drastically. > I think it's much nicer experience for the user to interact with ISPN as whole as an XAResource instead of Infinispan exposing the fact that its store might be XA as well. +1 Bottomline it's not impossible right?

_______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev