Re: computational model of transactions

Marshall wrote:
> ...
> It seems to me that much or maybe all of the difficulty with multiple
> concurrent transactions operating on the same data would be
> eliminated if it wasn't possible for a transaction to read back
> the results of its own writes.
> ...

I'll offer another reaction to this in the hope of showing that that multiple concurrent transactions is a smaller part of a bigger question, consistency (in what I think is Bob B's sense of correctness), ie., talking about concurrent difficulties is a limited, though not impractical, way to talk about accuracy.

Suppose I want to update the account balance only if it exceeds the amount of my withdrawal (this is to do with the balance my program reads as well as writes from the accounts table) and as well, only if the price of bananas in the bananas table is ten cents. Instead of reading the bananas table, an implementation could let me say the price I would want such a read to result in, without my program actually 'seeing' that result. Actually, the program doesn't even need to read the account balance if the application has no requirement to show that.

(Some locking theorists call the first requirement an 'escrow' lock. I would say those are not fundamental, just a special case of a 'transaction constraint'. BTW, I think SQL's SERIALIABLE was supposed to mean that if a second user updated the bananas table after my program read the accounts table but before it read the bananas table, my program would fail when it tried to read the bananas table - if mine read bananas before the second user's program read it, then that user's program would fail. I'm not sure what MVCC does here, but I suspect I would like it less than I like the program exceptions.)

p Received on Tue Aug 01 2006 - 20:46:42 CEST