Re: computational model of transactions

Brian Selzer wrote:
> "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.
> >

>

Let me stop you there Brian, because this is the sticking point, and I really think its a mistake. Statements (as distinct from 'entities') can only be correlated to each other by comparing similarities in the values of their fields, and thats it. There is simply nothing else _to them_ to compare. And certainly not with "this is the next version of the proposition" - there is no logical rhyme or reason for that. How could one justify thinking that there should? I think this is a common misintuition in how we view databases.

Just to qualify that - a next version of a 'conceptual entity', if one wants to think like that, is fine, but that's not what a database is holding (or ever should be at the logical level), it's just storing communicated statements. All best, J.

> 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.

> >>

> >> >>

> >> >> > 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

> >> >> results from another one.