Re: [infinispan-dev] rethinking ISPN transactions

huh? I must be missing something here, because that's not what I understand by 1PC. It's absolutely not the same as async. XA is built around the premise that you do not know, at the time the transaction begins, what resource(s) will be involved in it. The business logic in the transaction scope may contain different paths, resulting in different resources being enlisted or not. At transaction completion time the transaction manager checks how many have actually been enlisted. If it's only one, it optimizes out the 2PC and does a 1PC instead. In either case, it notifies the app of the outcome. That's not the same as an async commit, in which the app does not know the outcome. Nor does it imply a loss of consistency - if there are two data items in the same RM in the transaction, they must still be updated together in the 1PC. In that case you're essentially dealing with a subordinate transaction doing a 2PC over the data items, though it's only that hard if they are in different locations. In so far as you provide an XAResource implementation, it must support being called in 1PC mode. It may choose to do that by implementing a full 2PC internally, but that's usually slower. I'm really not clear what you gain by removing 1PC optimization. If it's weren't more efficient, it would not be there in the first place? Jonathan. On 11/08/2013 03:28 PM, Mircea Markus wrote: > Hey guys, > 4. Remove 1PC option > - I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing -- Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Paul Hickey (Ireland), Matt Parson (USA), Charlie Peters (USA) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev