At 06:49 PM 9/5/00 +0200, Bart Lateur wrote:
>On Tue, 05 Sep 2000 11:48:38 -0400, Dan Sugalski wrote:
>
> >>- two-phase commit handler, rollback coordinator (the above two is
> >> connected to this: very simple algorhythm!)
> >
> >Here's the killer. This is *not* simple. At all. Not even close.
> >
> >Doing this properly with data sources you completely control in a
> >multi-access situation (read: with threads) is *hard*.
>
>Is it?
>
>Here's some high-level emulation of what it should do.
>
> eval {
> my($_a, $_b, $c) = ($a, $b, $c);
> ...
> ($a, $b, $c) = ($_a, $_b, $_c);
> }
Nope. That doesn't get you consistency. What you need is to make a local
alias of $a and friends and use that. You also need to lock down those
variables so other threads will block if they write to them, and make
copies if they need to only read them.
It also means that if we're including *any* sort of external pieces (even
files) in the transaction scheme we need to have some mechanism to roll
back changes. If a transaction fails after truncating a 12G file and
writing out 3G of data, what do we do? And what does another thread that's
*only* reading that file during the transaction see? Does it block? Does it
see the pre-changed version? (Which is the normal course of action in
database systems)
This proposal's looking to roll in pretty much everything that makes a
modern relational database system really useful. (Whether SQL is useful is
an argument we won't get into at the moment... :) The ideas look simple on
the surface, but they have a huge number of ramifications, and implementing
them properly's not easy.
If we want to, that's great, but we do need to think it out really
carefully before we do.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
