Re: Re: AW: Re: MySQL and BerkleyDB (fwd)

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