Re: [dna-dev] Non-XA compliant resource participation in distributed transactions
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(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