Chaim Frenkel wrote:
> The problem I have with this plan, is reconciling the fact that a
> database update does all of this and more. And how to do it is a known
> problem, its been developed over and over again.
I'm sorry, but you are wrong. You are confusing transactions with
threading, and the two are fundamentally different. Transactions are
just a way of saying 'I want to see all of these changes, or none of
them'. You can do this even in a non-threaded environment by
serialising everything. Deadlock avoidance in databases is difficult,
and Oracle for example 'resolves' a deadlock by picking one of the two
deadlocking transactions at random and forcibly aborting it.
> Perl has full control of its innards so up until any data leaves perl's
> control, perl should be able to restart any changes.
>
> Take a mark at some point, run through the code, if the changes take,
> we're ahead of the game. If something fails, back off to the checkpoint
> and try the code again.
>
> So any stretch of code with only operations on internal structures could
> be made eligable for retries.
Which will therefore be utterly useless. And, how on earth will you
identify sections that "only operate on internal data"?
--
Alan Burlison
