computational model of transactions
Date: 1 Aug 2006 10:10:30 -0700
Message-ID: <1154452230.243215.174250_at_h48g2000cwc.googlegroups.com>
I've been thinking about concurrency and transactions. It occurs to me that much of the difficulty lies with the fact that multiple concurrent transactions may operate on the same data. I begin to recall some conversations from years past about "multiple assignment".
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.
In other words, consider the model in which transactions can only observe the database state that was current at the time the transaction started.
So, how much of a burden, at the *logical* level, would this be? Clearly it is not the same as with SQL transactions. Does it matter? Is there a use case I'm not thinking of that makes this problematic? I will admit there have been times where I've opened up an interactive SQL session, started a transaction, and typed a whole series of DML, and observed the results along the way, but I don't think I've ever written *code* that does anything like that.
Your experiences and thoughts are appreciated.
Marshall Received on Tue Aug 01 2006 - 19:10:30 CEST