[Persistence-sig] A simple Observation API

[Shane Hathaway]

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

> At 04:02 PM 7/30/02 -0400, Shane Hathaway wrote:
>
> >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.
>
> The only drawback I'm aware of for that approach, is that it leads to an
> infinite loop instead of a stack overflow, in the event you accidentally
> create a circular dependency graph.  The infinite loop doesn't produce a
> traceback, and thus doesn't show you *how* you created the circularity.

Good point.  OTOH, from my own experience, stack overflows in Python
sometimes lead to segfaults, and I'd prefer an infinite loop over a
segfault. :-)

> (snip)
>
> Also, I think a different method should be used for the second prepare()
> call - perhaps a flush() method.  That way, prepare() won't need to be able
> to be called twice during the same commit, which I can see some problems
> with.  prepare() could simply call flush(), or perhaps the transaction
> could do it.  flush() should be written so as to be usable at any point in
> the transaction, since it'll presumably be used to implement savepoints as
> well, and in some cases to ensure an underlying DB is up-to-date before
> performing a query.

Yes, flush() is a good idea.  It keeps the phase change distinct from the
repeatable messages, and its purpose would be well understood.

> I do like the simplification of not needing a "write-through" mode,
> although in reality all we are doing is replacing it with a "re-flush"
> mode.  That is, once a participant receives prepare(), it must respond to
> any future change notifications by requesting a re-call of flush() by the
> transaction.
>
> By the way, I'd still like to have the option of having participants join a
> transaction "permanently", in order to avoid all of the state management
> code that such things currently require.

Yes, that sounds useful for logging, periodic backups (to ensure the
backup is based on fully committed data), and other utilities.  As long as
joining permanently is optional, since objects like CommitVersions don't
need to stick around.

Now, I wonder about multithreaded apps.  If you join a transaction
permanently, do you join all threads?  At first I wasn't thinking you
would, but on further reflection, it seems like that's what you'd want.
And how would this affect CORBA (since, from what I hear, its transactions
are not bound to threads)?

> With the exception of the above issues, I'm good with this approach.
> Brilliant idea, Shane.  :)

Thanks.  You too.

Shane