Chaim Frenkel wrote:
> AB> I'm sorry, but you are wrong. You are confusing transactions with
> AB> threading, and the two are fundamentally different. Transactions are
> AB> just a way of saying 'I want to see all of these changes, or none of
> AB> them'. You can do this even in a non-threaded environment by
> AB> serialising everything. Deadlock avoidance in databases is difficult,
> AB> and Oracle for example 'resolves' a deadlock by picking one of the two
> AB> deadlocking transactions at random and forcibly aborting it.
>
> Actually, I wasn't. I was considering the locking/deadlock handling part
> of database engines. (Map row -> variable.)
Locking, transactions and deadlock detection are all related, but aren't
the same thing. Relational databases and procedural programming
languages aren't the same thing. Beware of misleading comparisons.
> How on earth does a compiler recognize checkpoints (or whatever they
> are called) in an expression.
If you are talking about SQL it doesn't. You have to explicitly say
where you want a transaction completed (COMMIT) or aborted (ROLLBACK).
Rollback goes back to the point of the last COMMMIT.
> I'm probably way off base, but this was what I had in mind.
>
> (I. == Internal)
>
> I.Object - A non-tied scalar or aggregate object
> I.Expression - An expression (no function calls) involving only SObjects
> I.Operation - (non-io operators) operating on I.Expressions
> I.Function - A function that is made up of only I.Operations/I.Expressions
>
> I.Statement - A statment made up of only I.Functions, I.Operations and
> I.Expressions
And if the aggregate contains a tied scalar - what then? The only way
of knowing this would be to check every item of an aggregate before
starting. I think not.
> Because if we can recover, we can take locks in arbitrary order and simply
> retry on deadlock. A variable could put its prior value into an undo log
> for use in recovery.
Nope. Which one of the competing transactions wins? Do you want a
nondeterministic outcome? Deadlocks are the bane of any DBAs life.
They are exceedingly difficult to track down, and generally the first
course of the DBA is to go looking for the responsible programmer with a
baseball bat in one hand and a body bag in the other. If you get a
deadlock it means your application is broken - it is trying to do two
things which are mutually inconsistent at the same time. If you feel
that automatically resolving this class of problem is an appropriate
thing for perl to do, please sumbit an RFC entitled "Why perl6 should
automatically fix all the broken programs out there and how I suggest it
should be done". Then you can sit back and wait for the phonecall from
Stockholm ;-)
--
Alan Burlison
