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

[Mark Little]

On 15 May 2008, at 15:36, Randall Hauch wrote:

>>
>> Why can't you make the file system transactional?
>
> I totally agree that a portion of a file system can be made to be  
> transactional for use by an application.  The problem is that if  
> some other application (that we don't control) starts using that  
> same portion of the file system in normal ways (which are not  
> transactional).  Our software could be written correctly, but it  
> some bozo configures it and allows some other 3rd party to access  
> it, the model breaks down.

The model breaks for any transaction approach if you don't enforce it  
or don't close any holes. With compensation transactions you're  
assuming that the undo (compensator) does the right thing, but some  
idiot could implement it wrongly or do something that the transaction  
infrastructure doesn't expect.

>
>
> My question really was whether it's still okay to create an XA  
> connector if there's a possibility of some bozo screwing things up  
> by accessing the underlying system.

Whatever approach you take you have to outline the rules and the  
implications of breaking those rules. All transaction models make  
assumptions (and rules) about the environment in which they work  
(e.g., with ACID transactions that a sys admin won't go in and release  
locks while the transaction is active).


>
>
> Another example system might be JIRA, which doesn't have the concept  
> in it's API for transactions.  (I can't add 3 issues, change 4  
> others, and delete another all in one request.)

If something isn't ACID transactional and doesn't make sense to be  
made so, then we should definitely stay clear. But my point is that  
this isn't clear cut. Plus, because the semantics are different,  
making the right choice may be forced on us.

>
>
>>
>>
>>>
>>>
>>> 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.
>
> Okay, this just answered my question.  You don't want to have XA  
> connectors to systems that don't have (can't be made to have) ACID  
> transactions, because you're essentially promising something you  
> cannot provide.  Here, you need to use compensating transactions.


Yes, but we need to agree that something can't be made ACID ;-)

Mark.

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