Re: computational model of transactions

Brian Selzer wrote:
"J M Davitt" <jdavitt@xxxxxxxxxx> wrote in message news:QVSAg.63281$Eh1.62802@xxxxxxxxxxxxxxxxxxxxxxxxx

Brian Selzer wrote:

"Brian Selzer" <brian@xxxxxxxxxxxxxxxxxxx> wrote in message news:voHAg.4447$uo6.79@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

"Erwin" <e.smout@xxxxxxxxxxx> wrote in message news:1154689817.830401.130180@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[snip]

The semantics of the update involve modification, not replacement

You obviously see a difference between modification and replacement. I
don't. So please explain.

[snip]

I'm back. I agree that the updates need to be isolated, but I disagree with the idea that the entire transaction needs to be isolated or serialized. It is only necessary to obtain an exclusive lock on the affected row at the time that the update to the shared resource occurs, so it's possible to have several other intervening transactions commit between the time that the transaction starts and the time that the update starts. My point is that it is not necessary to isolate the entire transaction, only that portion from the start of the update until the commit.

Are we to understand that "it's possible to have several other
intervening transactions commit between the time that the
transaction starts and the time that the update starts" means
that you believe that at "the time the update starts" the value
of whatever attribute is being changed isn't the same as it was
when the transaction started?


Yes. The nature of the update makes this possible. An update that simply decreases inventory by 5 need not know the state of the inventory at the time that the transaction started. If you issue,

[snip]

It would appear that you view "modification" and "replacement"
as two different sorts of updates. To the database engines
that are providing concurrency and correctness, those are
indistinguishable, AFAIK.

Also, your transactions seem like accounting system
concepts rather than database concepts.

While, in accounting, it seems to be possible to simply dump
all the debits and credits in a hopper and allow them to be
processed in random order, there comes a time when activity
must be serialized. The bookkeeper that's cross-footing
a page isn't going to be very happy with the clerk who wants
to change an entry that's been footed in one column but not
another.
.