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 Inouehttp://www.geocities.jp/inocchichichi/psqlodbc/

Tom Lane wrote:
> 
> 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