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

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).