>>>>> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
AB> 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.
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.)
>> So any stretch of code with only operations on internal structures could
>> be made eligable for retries.
AB> Which will therefore be utterly useless. And, how on earth will you
AB> identify sections that "only operate on internal data"?
How on earth does a compiler recognize checkpoints (or whatever they
are called) in an expression.
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
etc.
So any stretch of such could be made recoverable. It probably isn't
worth the effort and overhead. Possibly not good enough, but I don't
see it as impossible.
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.
It comes down to
. speed hit
. the 'random' nature of the recovery/ and recoverable stretchs
. eval
*sigh*
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
