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
someerror condition occurs. A single transaction can update many different databases. The two-phase commit strategy
isdesigned 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
monitorthen issues a "pre-commit" command to each database which requires an acknowledgment. If the monitor receives
theappropriate response from each database, the monitor issues the "commit" command, which causes all databases to
simultaneouslymake 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