Re: 2-phase commit

Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> The simplest senario(though there could be varations) is

> [At participant(master)'s side]
>   Because the commit operations is done, does nothing.

> [At coordinator(slave)' side]
>    1) After a while
>    2) re-establish the communication path between the
>       partcipant(master)'s TM.
>    3) resend the "commit requeset" to the participant's TM.
>   1)2)3) would be repeated until the coordinator receives
>   the "commit ok" message from the partcipant.

[ scratches head ] I think you are using the terms "master" and "slave"
oppositely than I would.  But in any case, this is not an answer to the
concern I had.  You're assuming that the "coordinator(slave)" side is
willing to resend a request indefinitely, and also that the
"participant(master)" side is willing to retain per-transaction commit
state indefinitely so that it can correctly answer belated questions
from the other side.  What I was complaining about was that I don't
think either side can afford to remember per-transaction state
indefinitely.  2PC in the abstract is a useless academic abstraction ---
where the rubber meets the road is defining how you cope with failures
in the commit protocol.

			regards, tom lane