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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/dna-dev
>
>
_______________________________________________
dna-dev mailing list
dna-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev