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

[Mark Little]

Do you mean federated within the same VM or across VMs?

Mark.


On 15 May 2008, at 14:21, Randall Hauch wrote:

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

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