Re: 2-phase commit

I seem to have misunderstood the problem completely.
I apologize to you all(especially Tom) for disturbing
this thread.

I wonder if there might be such a nice solution when
some of the systems or communications are dead.
And as many people already mentioned, there's not so
much allowance if we only adopt XA-based protocol.

regards,
Hiroshi Inoue
http://www.geocities.jp/inocchichichi/psqlodbc/

Tom Lane wrote:
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)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