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".
Transaction concurrency is an independent problem from integrity and should be dealt with *separately*..However preserving integrity is superior interest...

> 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.
A ridiculous assumption...

This kind of claim is equivalent to state that DBMS's should not be supporting versionning to work better. A total breach of data independence...How can integrity be preserved then? . A read access should ALWAYS access to the last committed version of the data written not just the data written on a just-in-time basis else you take a huge risk at corrupting your data.

Last week I had the example of an application opening 2500 UPDATE/SELECT (update on Table1 based on a selects on Table1) transactions in 5 minutes. Among the 2500 transactions 1500 were committed and 1000 were rolled back after 1 hour...Do you have any idea of how the data would look like on Table1 if the SELECT's were not made on a committed version of the data?

> In other words, consider the model in which transactions can only
> observe the database state that was current at the time the
> transaction started.
Much more complex than that. Impossible to handle by using SQL DBMS.

> So, how much of a burden, at the *logical* level, would this be?
Burden is not the least of problems if you trade integrity fro concurrency...It's a loose/loose choice...

> 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.
Don't. A pure waste of time.

> Your experiences and thoughts are appreciated.
Few pointers...
Check articles about *Read Consistency* (Oracle), *versionning* (general) and *READ_COMMITED_SNAPSHOT* (SQL Server)

> Marshall
Received on Tue Aug 01 2006 - 20:10:50 CEST