Re: computational model of transactions

Marshall wrote:
> 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

Have you read the book that was recoomended when you asled about MVCC ? It's an undergadute level textbook that treats questions like "much of the difficulty lies with the fact that multiple concurrent transactions may operate on the same data" very well. Received on Wed Aug 02 2006 - 22:28:21 CEST