Re: [infinispan-dev] CacheStore redesign: no XA cache stores
Sent from my iPhone On 31 Jul 2013, at 17:01, Sanne Grinovero wrote: > On 31 July 2013 16:01, Mircea Markus wrote: >> >> On 30 Jul 2013, at 23:12, Sanne Grinovero 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? It is not :-) > ___ > 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
Re: [infinispan-dev] CacheStore redesign: no XA cache stores
On 31 July 2013 16:01, Mircea Markus wrote: > > On 30 Jul 2013, at 23:12, Sanne Grinovero 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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] CacheStore redesign: no XA cache stores
On 30 Jul 2013, at 23:12, Sanne Grinovero 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. > > 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 ? 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
Re: [infinispan-dev] CacheStore redesign: no XA cache stores
> [...] , but I don't understand why the fact that it's running on a different process is limiting in any form. You are correct, it is not limiting. XA is process locality independent. Individual TXN participants (heterogeneous or homogeneous) register as XA resources (via JTA) with a central TM (which, if JTS compliant, supports XA). The TM then basically implements a classic 2PC to bound the scope of the TXN processing and outcome. An example of an XA transaction with heterogeneous participants could be a database (viewed by the TM as a resource=javax.sql.XADataSource) and a Queue (viewed by the TM as resource=javax.jms.XAQueueConnection). BTW, though not done in the JCache 1.0 draft, an ideal Java API in support of Cache as XA participant will be realized when JSR-107 provides something like a javax.cache.XACacheSource. -- View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-CacheStore-redesign-no-XA-cache-stores-tp4027770p4027772.html Sent from the Infinispan Developer List mailing list archive at Nabble.com.___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
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 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
