Re: computational model of transactions
Date: Sun, 06 Aug 2006 00:06:03 GMT
Message-ID: <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.
>>>>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.
>>>
>>>
>
Received on Sun Aug 06 2006 - 02:06:03 CEST