
> 1. For 1st phase we'll place into log "prepared-to-commit" record
>    and this phase will be accomplished after record is 
> flushed on disk.
>    At this point transaction may be committed at any time because of
>    all its modifications are logged. But it still may be rolled back
>    if this phase failed on other sites of distributed system.

1st phase will also need to do all the delayed constraint checks,
and all other work a commit currently does, that could possibly lead 
to a transaction abort. The 2nd phase of 2phase commit is not 
allowed to return an error, unless of course in case of catastrophe.

> 2. When all sites are prepared to commit we'll place "committed"
>    record into log. No need to flush it because of in the event of
>    crash for all "prepared" transactions recoverer will have to
>    communicate other sites to know their statuses anyway.
> 
> That's all! It is really hard to implement distributed lock- and
> communication- managers but there is no problem with logging two
> records instead of one. Period.

yup :-) Maybe this could even be raised to the SQL level, 
so applications could use this ? I have not seen this elsewhere,
but why actually not ?

Andreas

Wed, 24 Jan 2001 10:19:36 +0100
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at>
AW: Re: AW: Re: MySQL and BerkleyDB (fwd)
> yup :-) Maybe this could even be raised to the SQL level, 
> so applications could use this ? I have not seen this elsewhere,
> but why actually not ?

  Yes please :-) if someone is to code this quicker than me (I suppose
so, since I have other projects to deal with concurrently).

-- 
<< Tout n'y est pas parfait, mais on y honore certainement les jardiniers >>

			Dominique Quatravaux <dom@kilimandjaro.dyndns.org>

Thu, 25 Jan 2001 15:49:03 +0100
dom@idealx.com
Re: Re: AW: Re: MySQL and BerkleyDB (fwd)