Rollback in 2 phase commit

Question

I understand the 2 phase commit architecture. Let there be 2 slaves and 1 master and the all prepare phases went fine. When the master askede slave 1 to commit, the commit was fine. When master asked slave 2 to commit, it failed. So the master now needs to rollback the entire transaction. My queston is how slave 1 will now rollbakc since it has already committed? From my knowledge, commits are full and final. There maybe save points or journals on disk to restore state but that may require DBA assistance.

Reference on SO - Can a transaction be rolled back after it's committed and connection is closed?

Answer 1

That is normally not possible. The prepare phase of a two-phase commit should do everything necessary to make the transaction durable, except making it visible to others. After a prepare has been completed successfully a commit should always be possible. Once a two-phase commit has been committed it cannot be backed out.

If a commit of an already prepared transaction fails (eg because the resource is temporarily unavailable), then the resource manager should be able to recover the transaction and retry the commit. If this is not possible, then the resource doesn't support true two-phase commit and is probably faking it (for example by ignoring the prepare call).

So the successful commit should not be rolled back, but the failed commit should be retried!

Answer 2

2 phase commits actually means commits happens in 2 phases and not specially over two data endpoints. From your example I am getting an impression that you assume that 2 slaves involved in a commit means 2 phases. That is not correct. The first phase of the commit (which the slave 1 responded to as doable) is not actually propagated downwards by the slave 1. So essentially when the slave 1 says commit in phase1, its more of a memento copy which it keeps in memory. It doesn't actually issue a commit on the underlying data source. When Salve 2 says rollback for first phase, the master issues a rollback to salve 1 as well which can easily do it since nothing was persisted or propagated downstream yet.

however if slave 2 also says commit, the master issues a second phase commit instructions to both the slaves to actually send the commit operations downstream to their data sources. Now the involving parties in this operations can be 2 (like in your example) or many more. You can read more about it in details online. Just Google for XA transactions and 2 Phase protocols. In short remember that first phase is more of a soft commit where each participating end point just say 'if it can do a commit or not' second phase is the actual hard commit one.