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

>   I had thought that the pre-commit information could be stored in an
> auxiliary table by the middleware program ; we would then have
> to re-implement some sort of higher-level WAL (I thought of the list
> of the commands performed in the current transaction, with a sequence
> number for each of them that would guarantee correct ordering between
> concurrent transactions in case of a REDO). But I fear I am missing

This wouldn't work for READ COMMITTED isolation level.
But why do you want to log commands into WAL where each modification
is already logged in, hm, correct order?
Well, it has sense if you're looking for async replication but
you need not in two-phase commit for this and should aware about
problems with READ COMMITTED isolevel.

Back to two-phase commit - it's easiest part of work required for
distributed transaction processing.
Currently we place single commit record to log and transaction is
committed when this record (and so all other transaction records)
is on disk.
Two-phase commit:

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

2. When all sites are prepared to commit we'll place "committed"  record into log. No need to flush it because of in
theevent of  crash for all "prepared" transactions recoverer will have to  communicate other sites to know their
statusesanyway.
 

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.

Vadim