Re: computational model of transactions
- From: "Brian Selzer" <brian@xxxxxxxxxxxxxxxxxxx>
- Date: Sun, 06 Aug 2006 22:41:46 GMT
"J M Davitt" <jdavitt@xxxxxxxxxx> wrote in message
news:s8tBg.45500$vl5.15921@xxxxxxxxxxxxxxxxxxxxxxxxx
Brian Selzer wrote:
"J M Davitt" <jdavitt@xxxxxxxxxx> wrote in message
news:BZjBg.56521$u11.18671@xxxxxxxxxxxxxxxxxxxxxxxxx
[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?
.
- References:
- computational model of transactions
- From: Marshall
- Re: computational model of transactions
- From: Brian Selzer
- Re: computational model of transactions
- From: vc
- Re: computational model of transactions
- From: Brian Selzer
- Re: computational model of transactions
- From: Erwin
- Re: computational model of transactions
- From: Brian Selzer
- Re: computational model of transactions
- From: Erwin
- Re: computational model of transactions
- From: Brian Selzer
- Re: computational model of transactions
- From: Brian Selzer
- Re: computational model of transactions
- From: J M Davitt
- Re: computational model of transactions
- From: Brian Selzer
- Re: computational model of transactions
- From: J M Davitt
- Re: computational model of transactions
- From: Brian Selzer
- Re: computational model of transactions
- From: J M Davitt
- Re: computational model of transactions
- From: Brian Selzer
- Re: computational model of transactions
- From: J M Davitt
- Re: computational model of transactions
- From: Brian Selzer
- Re: computational model of transactions
- From: J M Davitt
- Re: computational model of transactions
- From: Brian Selzer
- Re: computational model of transactions
- From: J M Davitt
- computational model of transactions
- Prev by Date: Re: computational model of transactions
- Next by Date: Re: computational model of transactions
- Previous by thread: Re: computational model of transactions
- Next by thread: Re: computational model of transactions
- Index(es):
Relevant Pages
|