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

Michael Neale michael.neale at gmail.com
Thu May 15 17:28:40 EDT 2008


+1 on filessystems. That could be pretty common.

Sent from my iPhone

On 15/05/2008, at 7:28, Randall Hauch <rhauch at redhat.com> 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



More information about the dna-dev mailing list