Re: computational model of transactions
Date: Sat, 05 Aug 2006 22:16:44 GMT
Message-ID: <gN8Bg.3439$FN2.403_at_newssvr14.news.prodigy.com>
"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 - 00:16:44 CEST