[Persistence-sig] A simple Observation API

[Shane Hathaway]

On Tue, 30 Jul 2002, Phillip J. Eby wrote:

> They're messages, not phases.  The phase is the period between messages.

Yep. :-)

> Let's say we have DM1, DM2, and DM3, and the transaction calls:
>
> DM2.prepare()
> DM3.prepare()
> DM1.prepare()
>
> DM2.vote()
> DM3.vote()
> DM1.vote()
>
> If DM1 writes to DM3, and DM3 writes to DM2, then this ordering doesn't
> work, unless you have a "write-through" phase between prepare() and vote().
>  That is, if DM3 goes into "write-through" mode when it receives prepare(),
> then it will write through to DM2 when DM1 writes to it during the
> DM1.prepare() method.

I see now.  From one perspective, this problem is a side effect of keeping
transaction participants registered between transactions, as you've been
suggesting.  ZODB 3's transaction manager would normally have no problem
with this, since DM3 and DM2 would only get added to the transaction once
DM1 started writing.  The implicit order would solve the problem.

Unfortunately, this solution has a weakness--if some other data manager
wrote unrelated data to DM3 or DM2 before DM1 wrote its data, the implicit
order would be incorrect.  Thus the need for transaction agents, which
guarantee a specific order (if I recall correctly).

Write-through mode seems like a performance killer for many applications.
What about this: transaction participants could tell the transaction that
even though their prepare() method has been called already, they need it
called again.

Shane