Re: 2-phase commit

> > > > 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.
> >
> > Oops my mistake, sorry.
> > But is it 2-phase commit protocol in the first place ?
>
> That is, in your exmaple below
>
>  Example:
>
>         Master          Slave
>         ------          -----
>         commit ready-->

This is the commit for phase 1. This commit is allowed to return all
sorts of errors, like violated deferred checks, out of diskspace, ...

>                         <--OK
>         commit done->XX

This is commit for phase 2, the slave *must* answer with "success"
in all but hardware failure cases. (Note that instead the master could
instead send rollback, e.g. because some other slave aborted)

> is the "commit done" message needed ?

So, yes this is needed.

Andreas