[infinispan-dev] rethinking ISPN transactions

[Mircea Markus]

Hi Jonathan,

The 1PC that I'm referring to doesn't have to do at with the JTA/XA 1PC optimization. Infinispan allows a configurable number of nodes (processes) on which every key-value pair is stored - these are called data owners. When a key-value update happens, Infinispan internally uses an 2PC protocol in order to update all the data owners atomically: sends a prepare to propagate the data and acquire the lock (1PC) and then sends a commit (assuming the prepare was successful) to apply the modifications. Note that we run this 2PC protocol internally even if the TM does the 1PC optimization you mentioned below (pretty much for the same reasons as the TM does it though, i.e. in order to reach consensus but this time between ISPN nodes).

ATM Infinispan can be configured not to use an 2PC protocol internally, but a 1PC. When doing this there's no guarantee that an update happens on all the data owners, hence my question on whether this function is of any use.  


On Nov 21, 2013, at 4:06 PM, Jonathan Halliday <jonathan.halliday at redhat.com> wrote:

> 
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)