Re: computational model of transactions

From: JOG <jog_at_cs.nott.ac.uk>
Date: 7 Aug 2006 05:40:34 -0700
Message-ID: <1154954434.563615.217490_at_75g2000cwc.googlegroups.com>


Bob Badour wrote:
> J M Davitt wrote:
>
> > Brian Selzer wrote:
> >
> >> "J M Davitt" <jdavitt_at_aeneas.net> wrote in message
> >> news:LnaBg.63487$Eh1.25115_at_tornado.ohiordc.rr.com...
> >>
> >>> Brian Selzer wrote:
> >>>
> >>>> "J M Davitt" <jdavitt_at_aeneas.net> wrote in message
> >>>> news:AG6Bg.53697$u11.51832_at_tornado.ohiordc.rr.com...
> >>>>
> >>>>> Brian Selzer wrote:
> >>>>>
> >>>>>> "J M Davitt" <jdavitt_at_aeneas.net> wrote in message
> >>>>>> news:3d2Bg.44572$vl5.12370_at_tornado.ohiordc.rr.com...
> >>>>>>
> >>>>>>> Brian Selzer wrote:
> >>>>>>>
> >>>>>>>> "J M Davitt" <jdavitt_at_aeneas.net> wrote in message
> >>>>>>>> news:QVSAg.63281$Eh1.62802_at_tornado.ohiordc.rr.com...
> >>>>>>>>
> >>>>>>>>> Brian Selzer wrote:
> >>>>>>>>>
> >>>>>>>>>> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> >>>>>>>>>> news:voHAg.4447$uo6.79_at_newssvr13.news.prodigy.com...
> >>>>>>>>>>
> >>>>>>>>>>> "Erwin" <e.smout_at_myonline.be> wrote in message
> >>>>>>>>>>> news:1154689817.830401.130180_at_75g2000cwc.googlegroups.com...
> >>>>>>>
> >>>>>>> [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?
>
> A compiler can but would it? How many language grammars have you seen
> that had the following assignment productions:
>
> <varname> = <literal>
> <varname> = <varname> + <literal>
> ...
>
> instead of
>
> <varname> = <expression>
>
>
> >>> 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.
>
> What about the following?
>
> UPDATE Inventory
> SET QOH = (
> SELECT MIN( i2.QOH - 5 )
> FROM Inventory i2
> WHERE PartNo = '123'
> AND Location = 'ABC'
> )
> WHERE PartNo = '123'
> AND Location = 'ABC'
>
>
> >> 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.
> >
> > Holy bat, Crapman!
>
> He is full of it, isn't he?
>
>
> "As an aside" you've either abandoned
> > the points you made earlier in this thread or have been
> > using terminology inconsistently.
>
> Or he has neither a clue nor a place to put one. He has already
> demonstrated that he is an idiot who speaks more to hear his own voice
> than for any other reason.

While I understand your frustration, I do not believe this. The views purported by the OP are extremely common - how many times have we read similar? - and from that one has to conclude that for many they are a natural, perhaps intuitive mistake that goes beyond ignorance of the facts, and that this makes them extremely hard to shake.

I say this from my own experience with having to revise my thinking and the duress this took. (Similar problems have been documented with assessing probability. Even when taught the statistical underpinnings, people find their instinctive beliefs incredibly hard to shift.) Received on Mon Aug 07 2006 - 14:40:34 CEST

Original text of this message