Re: Consistency of distributed transactions - Mailing list pgsql-general

From Craig Ringer
Subject Re: Consistency of distributed transactions
Date
Msg-id 4DE5B45B.8050108@postnewspapers.com.au
Whole thread Raw
In response to Re: Consistency of distributed transactions  (Rob Sargent <robjsargent@gmail.com>)
List pgsql-general
On 06/01/2011 11:11 AM, Rob Sargent wrote:

> My recollection of distributed transactions is that the manager tells
> all players to do their thing. Then they each tell the manager "ok, did
> the deed". Then, if all players say ok, each of them is told by the
> manager to go ahead and commit, else rollback. Sorry, I don't recall the
> procedure for commit failure but I think you're in manual undo-land at
> that point.

Distributed transactions only work well when all participants (or all
but one participant) support two phase commit or a similar scheme where
they can almost totally guarantee a successful commit. The idea is that
each participant is told "I'm done doing work, prepare to commit and
tell me when you can guarantee - as far as is ever possible - that
commit will succeed". Once each participant affirms, the transaction
manager can tell each to go ahead and be - almost - totally confident
that all will go well.

See:
http://www.postgresql.org/docs/current/static/sql-prepare-transaction.html

http://en.wikipedia.org/wiki/Two-phase_commit_protocol

Of course, even with 2PC it's possible that something will go wrong when
the final commit is issued, but it's (a) extremely unlikely and (b)
likely that the failure can be remedied later by successfully applying
the changes, rather than having to roll everything  back across all the
servers.

A good example of where 2PC is important: think ATMs. There are two
transactions - the writing of the accounting records, and the vending of
cash. It is utterly vital that both succeed or fail together,  but one
is a physical operation that cannot be rolled back or undone. So you do
the account updates, do the logical equivalent of PREPARE TRANSACTION to
make sure the changes are on record and safe but not yet applied, vend
the cash, and then COMMIT PREPARED. If the cash roller jammed, you can
ROLLBACK PREPARED.

(Of course, if the UPS has a hiccup between PREPARE TRANSACTION and
COMMIT PREPARED, you don't know for sure if you successfully vended the
cash, only that you intended to. You have to examine the ATM to find
out, but then you can decide whether to commit or rollback the prepared
transaction(s),  instead of having to shrug your shoulders and say "er,
yeah, we vended some cash but we don't know to whom or when because we
lost those open transactions in a power failure").

--
Craig Ringer

pgsql-general by date:

Previous
From: Rob Sargent
Date:
Subject: Re: Consistency of distributed transactions
Next
From: Prafulla Tekawade
Date:
Subject: Psql Internal Variable question