Re: computational model of transactions
Date: Mon, 07 Aug 2006 14:17:45 GMT
Message-ID: <dYHBg.2305$o27.104_at_newssvr21.news.prodigy.com>
"JOG" <jog_at_cs.nott.ac.uk> wrote in message
news:1154955541.250800.254900_at_m79g2000cwm.googlegroups.com...
> Brian Selzer wrote:
>> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
>> news:1154690573.601286.285520_at_i3g2000cwc.googlegroups.com...
>> > Erwin wrote:
>> >> > It is not always the case that if more than one actor is
>> >> > updating the same resource, that those updates must be serialized.
>> >>
>> >> I leave that one on your account.
>> >>
>> >> > To illustrate this, ignore the business rules in the above example.
>> >>
>> >> Ignoring business rules is not my idea of a good example. And
>> >> especially not this kind of example, since I've been a bank programmer
>> >> for 15 years. I can assure you no one in the bank business would
>> >> accept the kind of risky manipulations with account balances that you
>> >> propose.
>> >>
>> >> > The semantics of the update involve modification, not replacement
>> >>
>> >> You obviously see a difference between modification and replacement.
>> >> I
>> >> don't. So please explain.
>> >
>> > I've noticed that this has cropped up a lot recently, where there
>> > exists a belief that one is changing part of a fact, as opposed to the
>> > truth that one is deleting a now incorrect fact, and inserting a brand
>> > new one. It appears a primary example where a common and understandable
>> > intuition is misleading.
>> >
>>
>> No, the circumstances underpinning a fact have changed, and the database
>> must be changed to reflect that. A true statement is either an axiom or
>> reflects circumstances that exist in a real or conceptual frame of
>> reference
>> that is called the universe of discourse. Axioms are always true and can
>> stand by themselves, otherwise they wouldn't be called axioms; therefore,
>> the only statements in a database that can change are those that reflect
>> circumstances that exist in the universe. There is no contest in the
>> chicken/egg debate when it comes to which comes first: a database
>> contains
>> knowledge about the universe, so when a change occurs, it occurs first in
>> the universe and then becomes known by the database. So if circumstances
>> change in the universe such that a statement about something relevent to
>> the
>> discussion that was known to be true no longer is, then it follows that
>> that
>> statement must be altered to reflect the new circumstances. In the same
>> way, if circumstances change such that something new becomes relevant,
>> then
>> new statements must be added to reflect that change. Similarly, if
>> circumstances change such that something that was relevant no longer is,
>> then the statements about that thing must be removed.
>>
>> Relations are a sound mechanism to classify statements about things so
>> that
>> the discussion can be directed toward some goal. The predicate of a
>> relational database not only classifies the statements contained within
>> but
>> also limits the scope of the discussion. The presence in a relation of a
>> statement about something indicates that that thing is relevant to the
>> discussion. For example, if a relation contains statements about the
>> location of people, then if someone's location changes, then there must
>> be
>> corresponding statements in the database states preceding and succeeding
>> the
>> change. The absence of a statement in the succeeding database state
>> implies
>> that that person's location is no longer relevant; the presence of an
>> additional statement implies that an additional person's location has
>> become
>> relevant.
> > Brian, we are dealing with propositions. Propositions _do not_ change, > they are either true or false, and that's it. There is no way past > this. Now we _can_ extract information about our external 'conceptual > entities' by examining these facts and matching identifying attributes > for them. We can even look at previous states of the database to see > how the facts that concerned them have changed. >
I understand that we're dealing with propositions. But a proposition reflects some facet of a snapshot of the universe. If it is possible to correlate a proposition in one database state with one in the next, then it is possible to compare the two propositions that reflect the same facet of the universe in successive database states: it is possible to describe how each attribute is different; therefore, it is possible to describe how the attributes in the succeeding proposition must be different than those in the preceeding one in order to reflect the current circumstances surrounding that facet of the universe. I understand that propositions do not change, but it's easier to say "the proposition must change to reflect current circumstances," than "the corresponding proposition in the succeeding database state must have attribute values that differ from those in the preceding state in order to denote the circumstances surrounding that facet of the universe reflected by each proposition that correspond to the succeeding database state."
>> (This is why I argued in an earlier thread that statements in one
>> database state must be able to be correllated with statements in the
>> next:
>> how else would you be able to tell what changed, what became interesting,
>> and what should now be ignored.)
> > By examining those identifying attributes for our external entity. If > there is no consistent identifying attributes between database states > for that 'entity' across our statements of fact, that task is utterly > impossible, and one has highlighted a serious design flaw not a problem > with the relational theory. > > So I agree that 'conceptual entities' can slowly change their > characteristics. But propositions cannot - I think it is due to a > conflation of these two concepts that confusion arises. At least it did > for me. All best Jim. > > >>
>> Thus, a statement that is no longer true must either be modified to
>> reflect
>> the new state of the object of the statement, or it must be removed to
>> reflect that the information is no longer relevant.
>>
>> There is a significant difference between modification and replacement.
>>>> >> results from another one.
>> >>
>> >> > the operation
>> >> > involved, addition, is communitive and associative.
>> >>
>> >> You mean "commuTAtive", of course, and furthermore that's completely
>> >> irrelevant. As for associativity : it is important to observe that
>> >> each transaction in this example does exactly one addition with
>> >> exactly
>> >> two arguments. So unless you can think of a way for the system to
>> >> detect that multiple independent transactions are doing such a thing
>> >> (performing an associative operation), and then replace those multiple
>> >> independent operations with one single, transaction-surpassing,
>> >> operation that has the same result, associativity is also irrelevant.
>> >> If you cannot think of such a way for the system to detect this (I'm
>> >> in
>> >> that case), you're stuck with doing multiple additions one-at-a-time,
>> >> and you're stuck with the fact that for the additions that are
>> >> executed
>> >> second and third, one of those arguments should be the result of the
>> >> former. Therefore it is necessary that the transactions be
>> >> serialized.
>> >> Otherwise it would mean a transaction is allowed to see uncommitted
>> >
> Received on Mon Aug 07 2006 - 16:17:45 CEST