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

[Randall Hauch]

Right.  Now I guess I have a question, tho, regarding the  
implementation of federation connectors to systems (e.g., file systems  
in particular) that don't have any natural support for transactions.   
Is implementing the connector as if it is XA-compliant a bad thing to  
do?

On May 15, 2008, at 3:59 AM, Mark Little wrote:

> 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).
>