How ACID is the two-phase commit protocol?

Question

I came across a situation where I started doubting whether the two-phase commit protocol really guarantees the ACID properties, especially the 'A' part of it.

Let's look at a theoretical distributed transaction involving 2 resources. (More practical description of the problem I had to deal with you can find in my blog). The scenario is a normal execution of a distributed transaction (no failures or recovery). An application starts a transaction, updates both resources and issues a commit() call. After commit is completed the application checks both resources and sees all the changes from the completed transaction. Everything is fine, the 2PC protocol did its job, right?

Now, a small change to the scenario. While the distributed transaction is doing commit(), another application is going to the same 2 resources. Can it see only part of the changes from the transaction? Let's say, changes to one resource are already visible while the changes to the second resource are not yet visible?

In all the information I have read on the 2PC protocol I could not find any guarantees about the visibility of the changes in the individual resources relative to each other. And I could not find anything that says that all the resources finish their individual commits at exactly the same time.

Answer 1

I think you are confusing topics. 2PC ensures that transactions commit with a certain visibility. I.e. in your transaction the data you commit will be ordered in a specific way and commits with that transactions will commit serially.

Outside of your transaction the behaviour you see will depend on how locking works in your database. Typically you would expect that a read-only query would either see the before transaction state or the after transaction state (with no guarantee per-se as to which it receives unless it is using the same locking semantics). Write semantics would typically result in locking all items in the transaction, but again this really depends on how your database is configured.

2PC really only promises that an operation is Atomic, and even then it is only necessarily atomic within the scope of that transaction depending on how your database is configured.

Answer 2

I think you're confusing 2PC with concurrency control. Two-phase commit ensures that all the participating threads in a transaction either commit or abort. Concurrency control ensures some sort of ordering of transactions in the same or separate applications. There are various ways of handling this depending on your requirements, but fully serialized transactions are certainly possible.