On Mon, Jan 22, 2001 at 12:41:38PM -0500, Joel Burton wrote:
> On Mon, 22 Jan 2001, Ross J. Reedstrom wrote:
>
> > And this case can be handled within one database by having multiple
> > schema, one for each package. It's not there yet, but it's a simpler
> > solution than the generic solution. The problem (as others have mentioned)
> > is that we don't want to open the door to remote access until we have a
> > two-phase transaction commit mechanism in place. Doing it any other way
> > is not a 'partial solution', it's a corrupt database waiting to happen.
>
> What does '2-phase transaction commit mechanism' mean in this case?
Same thing it means elsewhere. Typing "two phase commit" into Google gets me
this url:
http://webopedia.internet.com/Computer_Science/Transaction_Processing/two_phase_commit.html
Which says:
A feature of transaction processing systems that enables databases
to be returned to the pre-transaction state if some error condition
occurs. A single transaction can update many different databases. The
two-phase commit strategy is designed to ensure that either all the
databases are updated or none of them, so that the databases remain
synchronized.
Database changes required by a transaction are initially stored
temporarily by each database. The transaction monitor then
issues a "pre-commit" command to each database which requires an
acknowledgment. If the monitor receives the appropriate response from
each database, the monitor issues the "commit" command, which causes
all databases to simultaneously make the transaction changes permanent.
This 'pre-commit' 'really commit' two-step (get 'yer cowboy hats, right
here) is what's needed, and is currently missing from pgsql.
Ross
