Re: computational model of transactions


"J M Davitt" <jdavitt@xxxxxxxxxx> wrote in message
news:LnaBg.63487$Eh1.25115@xxxxxxxxxxxxxxxxxxxxxxxxx
Brian Selzer wrote:
"J M Davitt" <jdavitt@xxxxxxxxxx> wrote in message
news:AG6Bg.53697$u11.51832@xxxxxxxxxxxxxxxxxxxxxxxxx

Brian Selzer wrote:

"J M Davitt" <jdavitt@xxxxxxxxxx> wrote in message
news:3d2Bg.44572$vl5.12370@xxxxxxxxxxxxxxxxxxxxxxxxx


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.



Yes, I do. Modification depends on the current state of the attribute;
whereas replacement doesn't.
Database engines can provide concurrency and consistency, not
correctness, so in a replacement, the assumption is that the new value
is correct, and it's up to the application to correctly calculate the
new value; whereas with modification, the new value is calculated by the
database engine. This means that for replacement it's also up to the
application to request the correct level of concurrency, which can be
more restrictive for replacement than for modification.

Well, you're right about the consistent v. correct part, at
least in the sense that the system has no way to determine
whether or not what it's being asked to store is true in
the real world.

But you seem to have completely avoided my point that
"replacement" and "modification" are the same thing for the
database. How do you think the system can tell the difference?



Here's an example of a replacement:

UPDATE Inventory
SET QOH = 35
WHERE PartNo = '123'
AND Location = 'ABC'

Here's an example of a modification

UPDATE Inventory
SET QOH = QOH - 5
WHERE PartNo = '123'
AND Location = 'ABC'

I think it's pretty clear which is which. I think that the system should
be able to detect the difference just as you can.

Well, each of these specifies a value for a
column in a row in a table. You think
the expression denoting the value makes these
different and that the system should be able
to detect the difference. I'm still
wondering, "How?"


A compiler can tell the difference between x = 10 and x = x + 5, why can't a
dbms?

Exploring this a bit further: how many types
of UPDATEs is the system supposed to detect?
I mean, if we start by saying the number's
greater than one, how do we know when they
are all covered? Are you sure that
modification and replacement are all there
are?


The system should be able to detect whether or not the new value depends on
the previous value. The first UPDATE statement above does not, the second
does.

As an aside, it is not really necessary that the system detect this: but the
developer must, because in a concurrent environment the difference in the
semantics of replacement and modification has ramifications that can affect
the appropriate choice of transaction isolation level.

While we're talking manipulations: what about
INSERT and DELETE? Are there variants of
those, too? Are those supposed to be handled
differently in transaction context?


I haven't given this much attention, but at first glance, no, I don't think
so.

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.





.

Relevant Pages

  • Re: computational model of transactions
    ... replacement. ... disagree with the idea that the entire transaction needs to be ... the inventory at the time that the transaction started. ...
    (comp.databases.theory)
  • Re: computational model of transactions
    ... 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. ... Modification depends on the current state of the attribute; whereas replacement doesn't. ... Database engines can provide concurrency and consistency, not correctness, so in a replacement, the assumption is that the new value is correct, and it's up to the application to correctly calculate the new value; whereas with modification, the new value is calculated by the database engine. ...
    (comp.databases.theory)
  • Re: computational model of transactions
    ... replacement. ... transaction starts and the time that the update starts. ... Database engines can provide concurrency and consistency, ...
    (comp.databases.theory)
  • Re: computational model of transactions
    ... replacement. ... transaction starts and the time that the update starts. ... UPDATE Inventory ...
    (comp.databases.theory)
  • Re: computational model of transactions
    ... replacement. ... disagree with the idea that the entire transaction needs to be ... the inventory at the time that the transaction started. ... correctness, so in a replacement, the assumption is that the new ...
    (comp.databases.theory)