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