Re: computational model of transactions

Erwin wrote:
> > It is not always the case that if more than one actor is
> > updating the same resource, that those updates must be serialized.
>
> I leave that one on your account.
>
> > To illustrate this, ignore the business rules in the above example.
>
> Ignoring business rules is not my idea of a good example. And
> especially not this kind of example, since I've been a bank programmer
> for 15 years. I can assure you no one in the bank business would
> accept the kind of risky manipulations with account balances that you
> propose.
>
> > The semantics of the update involve modification, not replacement
>
> You obviously see a difference between modification and replacement. I
> don't. So please explain.

I've noticed that this has cropped up a lot recently, where there exists a belief that one is changing part of a fact, as opposed to the truth that one is deleting a now incorrect fact, and inserting a brand new one. It appears a primary example where a common and understandable intuition is misleading.

>
> > the operation
> > involved, addition, is communitive and associative.
>
> You mean "commuTAtive", of course, and furthermore that's completely
> irrelevant. As for associativity : it is important to observe that
> each transaction in this example does exactly one addition with exactly
> two arguments. So unless you can think of a way for the system to
> detect that multiple independent transactions are doing such a thing
> (performing an associative operation), and then replace those multiple
> independent operations with one single, transaction-surpassing,
> operation that has the same result, associativity is also irrelevant.
> If you cannot think of such a way for the system to detect this (I'm in
> that case), you're stuck with doing multiple additions one-at-a-time,
> and you're stuck with the fact that for the additions that are executed
> second and third, one of those arguments should be the result of the
> former. Therefore it is necessary that the transactions be serialized.
> Otherwise it would mean a transaction is allowed to see uncommitted
> results from another one.
Received on Fri Aug 04 2006 - 13:22:53 CEST