(We are not (quite) discussing what to do for Perl6 any longer. I'm
going though a learning phase here. I.e. where are my thoughts
miswired.)
>>>>> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
>> Actually, I wasn't. I was considering the locking/deadlock handling part
>> of database engines. (Map row -> variable.)
AB> Locking, transactions and deadlock detection are all related, but aren't
AB> the same thing. Relational databases and procedural programming
AB> languages aren't the same thing. Beware of misleading comparisons.
You are conflating what I'm saying. Doing locking and deadlock detection
is the mapping. Transactions/rollback is what I was suggesting perl
could use to accomplish under the covers recovery.
>> How on earth does a compiler recognize checkpoints (or whatever they
>> are called) in an expression.
AB> If you are talking about SQL it doesn't. You have to explicitly say
AB> where you want a transaction completed (COMMIT) or aborted (ROLLBACK).
AB> Rollback goes back to the point of the last COMMMIT.
Sorry, I meant 'C' and Nick pointed out the correct term was sequence
point.
>> 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
AB> And if the aggregate contains a tied scalar - what then? The only way
AB> of knowing this would be to check every item of an aggregate before
AB> starting. I think not.
What tied scalar? All you can contain in an aggregate is a reference
to a tied scalar. The bucket in the aggregate is a regular bucket. No?
>> 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.
AB> Nope. Which one of the competing transactions wins? Do you want a
AB> nondeterministic outcome?
It is already non-deterministic. Even if you lock up the gazoo, depending
upon how the threads get there the value can be anything.
Thread a Thread B
lock($a); $a=2; unlock($a); lock($a); $a=5; unlock($a);
Is the value 5 or 2? It doesn't matter. All that a sequence of locking
has to accomplish is to make them look as one or the other completed
in sequence. (I've got a reference here somewhere to this definition
of consistancy)
The approach that I was suggesting is somewhat akin to (what I
understand) a versioning approach to transactions would take.
AB> Deadlocks are the bane of any DBAs life.
Not any of the DBAs that I'm familiar with. They just let the application
programmers duke it out.
AB> If you get a deadlock it means your application is broken - it is
AB> trying to do two things which are mutually inconsistent at the
AB> same time.
Sorry, that doesn't mean anything. There may be more than one application
in a Database. And they may have very logical things that they need done
in a different order.
The Deadlock could quite well be the effect of the database engine. (I
know sybase does this (or at least did it a few revisions ago. It took
the locks it needed on an index a bit late.)
A deadlock is not a sin or something wrong. Avoiding it is a useful
(extremely useful) optimization. Working with it might be another
approach. I think of it like I think of ethernet's back off and retry.
AB> If you feel that automatically resolving this class of problem is
AB> an appropriate thing for perl to do.
Because I did it already in a simple situation. I wrote a layer that
handled database interactions. Given a set of database operations, I
saved a queue of all operations. If a deadlock occured I retried it
until successful _unless_ I had already returned some data to the
client. Once some data was returned I cleaned out the queue.
The recovery was invisible to the client. Since no data ever left my
service layer, no external effects/changes could have been made.
Similarly, all of the locking and deadlocks here could be internal
to perl, and never visible to the user, so taking out a series of
locks, even if they do deadlock, perl can recover.
Again, this is probably too expensive and complex, but it isn't
something that is completely infeasible.
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
