Re: computational model of transactions
Date: Sat, 05 Aug 2006 19:53:04 GMT
Message-ID: <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?
>>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 Sat Aug 05 2006 - 21:53:04 CEST