[infinispan-dev] rethinking ISPN transactions

[Jonathan Halliday]

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)