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

[Mark Little]

Any good transaction manger should implement LRCO and as long as the  
1PC resource doesn't break 1PC (i.e., it commits when it should and  
rolls back when it should).

Mark.


On 14 May 2008, at 22:38, John P. A. Verhaeg wrote:

> I'd agree - I wasn't suggesting to replace compensating  
> transactions, just to offer this as an additional option for those  
> that must, for whatever reason, use XA transactions.  I should also  
> clarify the type of non-XA resource I'm referring to must still at  
> least be transactional for the "XA-compliant" tag to still apply.
>
> 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).