On Tue, Nov 05, 2002 at 08:54:46PM +0900, Satoshi Nagayasu wrote:
>
>
> Hannu Krosing <hannu@tm.ee> wrote:
> > >
> > > In protocol-layer 2PC, no new SQL command is required.
> > > A precommit-vote-commit phase will be called implicitly. It means an
> > > user application can be used without any modification. An application
> > > can use a traditional way (BEGIN...COMMIT).
> >
> > If application continues to use just BEGIN/COMMIT, then the protocol
> > level must parse command stream and recognize COMMIT in order to replace
> > it with PRECOMMIT, COMMIT.
> >
> > If the communication library has to do that anyway, it could still do
> > the replacement without affecting wire protocol, no ?
No, I think Satoshi is suggesting that from the client's point of view,
he's embedded the entire precommit-vote-commit cycle inside the COMMIT
command.
> In my implementation, 'the extended(2PC) FE/BE protocol' is used only in
> the communication between the master and slave server(s), not between a
> client app and the master server.
>
> libpq <--Normal FE/BE--> (master)postgres <--Extended(2PC)FE/BE--> (slave)postgres
> <--Extended(2PC)FE/BE--> (slave)postgres
> <--Extended(2PC)FE/BE--> (slave)postgres
>
> A client application and client's libpq can work continuously without
> any modification. This is very important. And protocol modification
> between master and slave server(s) is not so serious issue (I think).
>
Ah, but this limits your use of 2PC to transparent DB replication - since
the client doesn't have access to the PRECOMMIT phase (usually called
prepare phase, but that's anothor overloaded term in the DB world!) it
_can't_ serve as the transaction master, so the other use cases that
people have mentioned here (zope, MOMs, etc.) wouldn't be possible.
Hmm, unless a connection can be switched into 2PC mode, so something
other than a postgresql server can act as the transaction master.
Does your implementation cascade? Can slaves have slaves?
Ross
