Is XA transaction ACID?

[ochaloup]

Hi,

by interest. I have a terminology (or transaction based theory) question. Our EAP documentation says

XA allows multiple resources, such as application servers, databases, caches, and message queues, to participate in the same transaction, while preserving all four ACID properties.

Is correct to say that XA transaction preserves all fourn ACID properties? When I try to recap it then

• Atomicity - all operations are executed as an atomic unit, all participants are either committed or rolled back
• Consistency - transaction brings each resource from one valid state to other valid consistent state
• Isolation - system behaves like the parallel transactions would be run in serial order
• Durabilty - once a transaction completes, all changes made during that transaction become persistent

From that point.

On consistency. We can say that after transaction ends system is consistent. But in case of fail there could be quite a long time (before recovery is processed etc.) when whole system is quite inconsistent. I mean one resource was committed and other is still waiting for being committed and querying it will return different state than that participant which was already committed.

On isolation is not maintained isn't it?

How can I understand that? Do I watch it wrong? Does XA transaction relaxes some of the ACID properties in fact? Or can you give me some reference where to search the answer?

Thanks for a clue

Ondra

[tomjenkinson]

Hi Ondra,

Thanks for the question, the resource manager should hold locks until recovery takes place (i.e. between pre-crash prepare and post-crash commit/rollback).

Hope that helps,

Tom

[ochaloup]

Ok, thanks, I see the point. My view was a bit narrow probably. I took it from way how standard DB settings works. I can do a change to DB and when it's not committed I'm able to read a state before transaction had started. That would not  be possible when serializable isolation level would be used. Then even the read to the a row which is part of a non-finished transaction needs to wait. Right?

[mmusgrov]

Ondřej Chaloupka wrote:

Ok, thanks, I see the point. My view was a bit narrow probably. I took it from way how standard DB settings works. I can do a change to DB and when it's not committed I'm able to read a state before transaction had started. That would not  be possible when serializable isolation level would be used. Then even the read to the a row which is part of a non-finished transaction needs to wait. Right?

That's right if the DBMS isolation level is Serializable but most applications do not run with this setting and the isolation level needs to be set on a per application basis. Using the other levels can mean that the application may see an inconsistent state if one of the resources has committed and made visible its changes.

[ochaloup]

Thanks Mike for the clarification.