[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