At 01:42 AM 9/4/00 +0200, dLux wrote:
>What it needs in the core is pretty small btw:
I think you underestimate things here a tad...
>- a new keyword, which is similar to "local"
Okay, that's small.
>- some extension to the TIE interface (some new callbacks)
As is this.
>- some extension to the object interface (new callbacks)
And this.
>- lock/mutex handler
This could piggy-back on the threaded code stuff.
>- 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*. It requires possibly
unbounded amounts of scratch space, a lot of cooperation with anything that
accesses external data sources (like DBD::Oracle, say), and either
cooperation or lots of sophisticated programming for things that stay
internal. (We would, for example, have to get very clever for code that
accesses external libraries if they didn't support the transaction
interface, possibly snapshotting and later replacing all the global state
they keep. Which may not be possible)
>then all things are very
>straightforward, aren't they? It is _not_ complicated at all. It is
>all Perlish!
This is far from straightforward. Keen, yes, but very far from
straightforward. It would also add a lot of code to the core, and possibly
place some heavy demands on the resources of machines running perl code.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
