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