[dna-dev] Non-XA compliant resource participation in distributed transactions

Mark Little mlittle at redhat.com
Thu May 15 04:59:24 EDT 2008


As I said in an earlier email, there are significant differences  
between compensating transactions and ACID transactions (of which XA  
is just one possible implementation). You shouldn't offer compensating  
transactions opaquely to users if they register multiple 1PC-aware  
resources because the semantics are different. Using them without  
understanding the implications can be a PITA at best and cause  
significant data inconsistencies at worse (compensations can fail or  
take an arbitrary amount of time to resolve). ACID transactions are a  
pretty good default. If users have multiple 1PC-aware resources then  
it may be in their best interests to convert them to 2PC rather than  
be lulled into some false sense of security that somehow a  
compensating transaction will give them the same guarantees.

Mark.



On 14 May 2008, at 22:28, Randall Hauch wrote:

> I agree that what you are suggesting is still transactional (except  
> for the last source, which is not transactional).  But we will  
> likely need to supporting several non-XA sources (e.g., file  
> systems, applications, etc.) within an XA system.  And, if we know  
> the individual changes to each node for each source, we shouldn't we  
> also be able to use compensating transactions to "rollback" changes  
> to the non-XA system?
>
> I think there's value to supporting both.  I just think the odds of  
> having more than one non-XA source is pretty high.
>
> On May 14, 2008, at 4:22 PM, John P. A. Verhaeg wrote:
>
>> The big difference here seems to be the exposure of the updates  
>> before the distributed transaction is committed.  What I'm  
>> suggesting is still XA-compliant, while compensating transactions  
>> are not.
>>
>> Randall Hauch wrote:
>>> This is the behavior allowed by JBoss Transactions (Arjuna), and  
>>> it seems useful.  However, I wonder if we can do compensating  
>>> transactions, is there still an advantage to supporting n-1 XA  
>>> plus 1 non-XA?
>>>
>>> Cheers,
>>>
>>> Randall
>>>
>>> On May 14, 2008, at 4:10 PM, John P. A. Verhaeg wrote:
>>>
>>>> Seems like we ought to strive to support n-1 XA resources for  
>>>> distributed transactions, allowing for the last participant in a  
>>>> transaction (thus, this participants updates can't be done in  
>>>> parallel with the other resources) to not support XA  
>>>> transactions, but still participate in a distributed transaction  
>>>> with other XA-compliant resources.  Unlike compensating  
>>>> transactions, the non-XA participant would appear transactional  
>>>> and none of the updates would be visible until the entire  
>>>> transaction was complete.  It seems like this could open up many  
>>>> more possible configurations for customers.
>>>> _______________________________________________
>>>> dna-dev mailing list
>>>> dna-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/dna-dev
>>>
>>>
>> _______________________________________________
>> dna-dev mailing list
>> dna-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/dna-dev
>
> _______________________________________________
> dna-dev mailing list
> dna-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/dna-dev

----
Mark Little
mlittle at redhat.com

JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod  
Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903  
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt  
Parsons (USA) and Brendan Lane (Ireland).




More information about the dna-dev mailing list