On 11/08/2015 02:46 PM, Michael Paquier wrote:
> On Sun, Nov 8, 2015 at 1:53 AM, Konstantin Knizhnik wrote:
>> In tsDTM approach two phase commit is performed by coordinator and currently
>> is using standard PostgreSQL two phase commit:
>>
>> Code in GO performing two phase commit:
>>
>> exec(conn1, "prepare transaction '" + gtid + "'")
>> exec(conn2, "prepare transaction '" + gtid + "'")
>> exec(conn1, "select dtm_begin_prepare($1)", gtid)
>> exec(conn2, "select dtm_begin_prepare($1)", gtid)
>> csn = _execQuery(conn1, "select dtm_prepare($1, 0)", gtid)
>> csn = _execQuery(conn2, "select dtm_prepare($1, $2)", gtid, csn)
>> exec(conn1, "select dtm_end_prepare($1, $2)", gtid, csn)
>> exec(conn2, "select dtm_end_prepare($1, $2)", gtid, csn)
>> exec(conn1, "commit prepared '" + gtid + "'")
>> exec(conn2, "commit prepared '" + gtid + "'")
>>
>> If commit at some of the nodes failed, coordinator should rollback prepared
>> transaction at all nodes.
> Not always. If COMMIT PREPARED fails at some of the nodes but succeeds
> on others, the transaction is already partially acknowledged as
> committed in the cluster. Hence it makes more sense for the
> coordinator to commit transactions on the remaining nodes. Before
> issuing any COMMIT PREPARED queries, I guess that's fine to rollback
> the transactions on all nodes though.
We will get inconsistency if transaction is committed on some subset of nodes involved in transaction.
Assume bank debit-credit example. If some distributed transaction transfers money from the account at one node to the
accountand another node,
then committing transaction just at one node cause incorrect total balance.
The main goal of DTM is to preserve ACID semantic for distributed transaction, so either transaction is committed at
allnodes, either it is not committed at all.
