Re: computational model of transactions
Date: Sun, 06 Aug 2006 22:41:46 GMT
Message-ID: <KeuBg.1586$1f6.1247_at_newssvr27.news.prodigy.net>
"J M Davitt" <jdavitt_at_aeneas.net> wrote in message
news:s8tBg.45500$vl5.15921_at_tornado.ohiordc.rr.com...
> Brian Selzer wrote:
>> "J M Davitt" <jdavitt_at_aeneas.net> wrote in message
>> news:BZjBg.56521$u11.18671_at_tornado.ohiordc.rr.com...
>
> [snip]
>
>>>Holy bat, Crapman! "As an aside" you've either abandoned
>>>the points you made earlier in this thread or have been
>>>using terminology inconsistently. When you started with
>
>> So the discussion diverged. I think it was you who introduced the system
>> into the argument, not me.
>
> "Diverged?" I don't think so. Besides an response to
> a post from Marshall, all my posts to this thread have
> been made trying to get clarification on points in
> your writings.
>
> You think *I* dragged "the system" into the argument?
> No way. Consider:
>
> - How can any discussion of the computational model
> of transactions avoid a system?
> - How do "other intervening transactions" exist
> without a system?
> - What was that "the system can tell the difference"
> all about?
>
>> My original argument is that there is a difference in semantics between
>> replacement and modification, and that that difference can affect
>> concurrency.
>
> I gathered that from
>
> Modification depends on the current state of the
> attribute; whereas replacement doesn't.
>
> and:
>
> I disagree with the idea that the entire
> transaction needs to be isolated or serialized.
>
> But, then, this seems out of place:
>
>> Whether any implementation is involved or not doesn't change that, nor
>> have any of the statements I've made been at odds with it.
>
>> I noticed the divergence of the discussion in the last post, so I thought
>> I'd try to bring it back on track with the aside. I certainly didn't
>> expect to be tarred and feathered as a result.
>
> If you're being tarred and feathered, it' not because
> you were bringing the discussion back on track.
>
> Speaking of which:
>
> [snip]
>
>>>I was about to move on to the question, "If the
>>>system can detect that a 'replacement' UPDATE is
>>>in the mix, why not require it to optimize the
>>>workload and discard all the 'modify' UPDATEs?"
Assuming that the above updates occur in different transactions, then if all of the above transactions are performing essentially the same computation but that for the replacement transaction the new value is calculated in the application yet for the modification transactions the new value is calculated by the system, then the system cannot discard any of the 'modify' UPDATEs because the replacement transaction must be completely isolated from all of the other transactions so that the value that the application reads in order to calculate the new value is current and not subject to change throughout the transaction.
Of course, if all of the updates occur in the same transaction, then any of the 'modify' UPDATEs that precede the 'replacement' UPDATE could indeed be discarded.
>
> Or is discussion of a system off-track?
Received on Mon Aug 07 2006 - 00:41:46 CEST