2

I am referring to the description of 2-phase commit at https://en.wikipedia.org/wiki/Two-phase_commit_protocol.

In the pre-commit phase, assume both resource managers have voted positively.

If the transaction manager initiates the commit by sending a COMMIT message to each resource manager and if only one of them returns an ACK, and the other does not, how does transaction manager rollback the already committed transaction from the first resource manager which succeeded in committing?

Isn't there a possibility of a transaction being committed on one resource manager and not the other while the global transaction has failed?

500 - Internal Server Error
  • 28,327
  • 8
  • 59
  • 66
Yash
  • 946
  • 1
  • 13
  • 28

2 Answers2

1

Yes, indeed.

In that case the transaction coordinator informs all parties, which successfully committed the transaction, that they must roll it back.

This should usually be a relatively rare condition caused by problems like hardware faults or running out of disk place. On many systems, the roll back involves undoing changes read from a journal file.

This is all explained in the article you link to as well.

500 - Internal Server Error
  • 28,327
  • 8
  • 59
  • 66
  • The Wiki page mentions that there are possibilities that manual steps may be required to fix issues left by a failed XA. Is there a set of steps one should take if XA fails? – Yash Dec 04 '15 at 16:26
  • On the systems I have worked with, if a transaction fails to roll back based on recorded journaling information, the database gets marked as corrupt (must be restored from back-up), but this is extremely rare. – 500 - Internal Server Error Dec 04 '15 at 16:55
0

I would say that it depends on implementation of transaction coordinator that you use and type of error that commit produces. (I'm familiar with Narayana transaction manager.)

On your first question - if a transaction participant commits then transaction coordinator does not have any generic way how to undo that. If discrepancy in 2PC happens (some participant commits and other fails) then transaction coordinator announces heuristic exception and is up to administrator to fix the thing manually. And yes, maybe you will need to use some internal DB journal in case.

But 2PC talks about 2 phases and the first one is here relevant. If all participants returns OK from prepare phase then it means that all participants create a record in their internal transaction logs. In case of DB it would be that when transaction is prepared and some rows are locked for change of other transactions. DB then waits for coordinator to drive the commit. If DB does not get order to commit it waits - e.g.if connection from coordinator to DB is interrupted then waits for connection being up again. Even that transaction coordinator fail to finish transaction at time (as connection crashed) it will (could) finish its work at time when connection is up again.

Now depends what failure happens. The example of connection crash is considered as a action that is temporary and transaction coordinator could finish work after connection is established back. If there is some serious issue then participant returns info about it to transaction coordinator and it then informs back to user with heuristic exception as mentioned above.

That's it - in case one participant could be committed and other rolled back as your second question states.

chalda
  • 702
  • 4
  • 18