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

Thu May 15 10:16:56 EDT 2008

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 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
>>>>
>>>> ----
>>>> Mark Little
>>>> mlittle at 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 at 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 at 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).