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

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

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

As I said in an earlier email, there are significant differences between compensating transactions and ACID transactions (of which XA is just one possible implementation). You shouldn't offer compensating transactions opaquely to users if they register multiple 1PC-aware resources because the semantics are different. Using them without understanding the implications can be a PITA at best and cause significant data inconsistencies at worse (compensations can fail or take an arbitrary amount of time to resolve). ACID transactions are a pretty good default. If users have multiple 1PC-aware resources then it may be in their best interests to convert them to 2PC rather than be lulled into some false sense of security that somehow a compensating transaction will give them the same guarantees. Mark. On 14 May 2008, at 22:28, 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 > > _______________________________________________ > dna-dev mailing list > dna-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/dna-dev ---- Mark Little mlittle(a)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).

Do you mean federated within the same VM or across VMs? Mark. On 15 May 2008, at 14:21, Randall Hauch wrote: > Right. Now I guess I have a question, tho, regarding the > implementation of federation connectors to systems (e.g., file > systems in particular) that don't have any natural support for > transactions. Is implementing the connector as if it is XA- > compliant a bad thing to do? > > On May 15, 2008, at 3:59 AM, Mark Little wrote: > >> As I said in an earlier email, there are significant differences >> between compensating transactions and ACID transactions (of which >> XA is just one possible implementation). You shouldn't offer >> compensating transactions opaquely to users if they register >> multiple 1PC-aware resources because the semantics are different. >> Using them without understanding the implications can be a PITA at >> best and cause significant data inconsistencies at worse >> (compensations can fail or take an arbitrary amount of time to >> resolve). ACID transactions are a pretty good default. If users >> have multiple 1PC-aware resources then it may be in their best >> interests to convert them to 2PC rather than be lulled into some >> false sense of security that somehow a compensating transaction >> will give them the same guarantees. >> >> Mark. >> >> >> >> On 14 May 2008, at 22:28, 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 >>> >>> _______________________________________________ >>> dna-dev mailing list >>> dna-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/dna-dev >> >> ---- >> Mark Little >> mlittle(a)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). >> > ---- Mark Little mlittle(a)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).

This could degenerate into a long discussion about transactions. I'll try not to have that happen ;-) On 15 May 2008, at 15:09, Randall Hauch wrote: > Well, I'm referring to federation as in DNA federation of multiple > sources into a single repository, where those sources may be remote > system or local systems. (Ignore for now that a DNA repository may > actually be hosted on a cluster, because each server in the cluster > will have the same setup of connectors.) > > A file system connector (or any other connector for that matter) > can certainly be made to implement the XA interfaces. But even if > a file system connector correctly implements "transactional" > behavior (even 2PC) and ACID semantics (such that other file system > connector instances accessing the same file system also respect > those transactions), the operations on the file system are not > truly ACID in a global sense. Another client could get in and > start changing the files on the file system without regard to those > semantics, and now those changes may leak into the connectors. So the easy answer to this is to state that your RM isn't actually obeying the transactional semantics. If you provide a backdoor to a resource that goes outside of transactionality, then you're just asking for trouble. The file system can be made transactional: JBossTS comes with a complete set of transactional file system adapters and a programming model based on them. So this is only a problem if the architecture allows it to occur.

Why can't you make the file system transactional?

> > > So my question is whether it's a bad thing to implement a connector > to a non-transactional system as if it is XA compliant, since the > "XA-compliance" is really a misnomer? My answer is still the same: you can make the file system transactional. If there is really a resource that cannot be made transactional (and by that I mean ACID transactions) then compensations (or some other extended transaction model) are the right approach. In that case, I wouldn't bother making them look like they are XA-aware. But I would also not hide this fact from users: the semantics are different.

Have you looked at WS-BA, for instance? Or the compensation framework within JBossTS? Mark. > > > On May 15, 2008, at 8:36 AM, Mark Little wrote: > >> Do you mean federated within the same VM or across VMs? >> >> Mark. >> >> >> On 15 May 2008, at 14:21, Randall Hauch wrote: >> >>> Right. Now I guess I have a question, tho, regarding the >>> implementation of federation connectors to systems (e.g., file >>> systems in particular) that don't have any natural support for >>> transactions. Is implementing the connector as if it is XA- >>> compliant a bad thing to do? >>> >>> On May 15, 2008, at 3:59 AM, Mark Little wrote: >>> >>>> As I said in an earlier email, there are significant differences >>>> between compensating transactions and ACID transactions (of >>>> which XA is just one possible implementation). You shouldn't >>>> offer compensating transactions opaquely to users if they >>>> register multiple 1PC-aware resources because the semantics are >>>> different. Using them without understanding the implications can >>>> be a PITA at best and cause significant data inconsistencies at >>>> worse (compensations can fail or take an arbitrary amount of >>>> time to resolve). ACID transactions are a pretty good default. >>>> If users have multiple 1PC-aware resources then it may be in >>>> their best interests to convert them to 2PC rather than be >>>> lulled into some false sense of security that somehow a >>>> compensating transaction will give them the same guarantees. >>>> >>>> Mark. >>>> >>>> >>>> >>>> On 14 May 2008, at 22:28, 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 >>>>> >>>>> _______________________________________________ >>>>> dna-dev mailing list >>>>> dna-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/dna-dev >>>> >>>> ---- >>>> Mark Little >>>> mlittle(a)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). >>>> >>> >> >> ---- >> Mark Little >> mlittle(a)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). >> > ---- Mark Little mlittle(a)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).

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

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