computational model of transactions

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

.

Relevant Pages

  • Re: ACID et al
    ... working on which in part has to do with guaranteeing the ACID properties without locking. ... wouldn't support concurrent transactions, only concurrent users! ... minimal code which at the same time means with a minimal interface/api ...
    (comp.databases.theory)
  • Re: Theoretical Basis for SELECT FOR UPDATE
    ... >> transactions from being concurrent to serial. ... > No, the comma operator has nothing to do with other, concurrent ... Assuming as you've said that the comma delimited sequence is unrelated ...
    (comp.databases.theory)
  • Re: computational model of transactions
    ... that much of the difficulty lies with the fact that multiple concurrent ... transactions may operate on the same data. ... should be dealt with *separately*..However preserving integrity is ...
    (comp.databases.theory)
  • Re: ACID et al
    ... >> paul c wrote: ... another way to say what I meant might be that such an implemention ... >>>wouldn't support concurrent transactions, only concurrent users! ...
    (comp.databases.theory)
  • Re: Performance Question for your collective consideration
    ... multiple regions he's still running MRO isn't he. ... limited knowledge, means he probably has TORs, AORs, and FORs, and ... several transactions could be in various stages of their processing at ... We do not use a TOR with multiple AORs running ...
    (bit.listserv.ibm-main)