Peter Eisentraut wrote:
>Tom Lane writes:
>
>
>
>>No. The real problem with 2PC in my mind is that its failure modes
>>occur *after* you have promised commit to one or more parties. In
>>multi-master, if you fail you know it before you have told the client
>>his data is committed.
>>
>>
>
>I have a book here which claims that the solution to the problems of
>2-phase commit is 3-phase commit, which goes something like this:
>
>coordinator participant
>----------- -----------
>INITIAL INITIAL
> prepare -->
>WAIT
> <-- vote commit
> READY
>(all voted commit)
> prepare-to-commit -->
>PRE-COMMIT
> <-- ready-to-commit
> PRE-COMMIT
> global-commit -->
>COMMIT COMMIT
>
>
>If the coordinator fails and all participants are in state READY, they can
>safely decide to abort after some timeout. If some participant is already
>in state PRE-COMMIT, it becomes the new coordinator and sends the
>global-commit message.
>
>Details are left as an exercise. :-)
>
>
Ok. Lets assume one coordinator, two partitipants.
Global commit send to both by coordinator. One replies with ok, the
other one remains silent.
What should the coordinator do? It can't fail the transaction - the
first partitipant has commited its part. It can't complete the
transaction, because the ok from the 2nd partitipant is still outstanding.
I think Bruce is right: It's an admin decision. If a timeout expires, a
user supplied app should be called, with a safe default (database
shutdown?).
-- Manfred
