Re: cdt glossary 0.1.1 (repost)

From: Brian Selzer <brian_at_selzer-software.com>
Date: Wed, 18 Apr 2007 05:27:05 GMT
Message-ID: <J_hVh.11045$YL5.5603@newssvr29.news.prodigy.net>

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:%qgVh.89055$6m4.56691_at_pd7urf1no...
> Brian Selzer wrote:

>> You need to correct the entry for Transaction.  See below.
>>
>> "mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message 
>> news:4620ae20$0$330$e4fe514c_at_news.xs4all.nl...
>> ...
>>>[Transaction]
>>>A set of database operations constituting a logical unit of work.
>>
>> [Transaction]
>> A sequence of database operations constituting a logical unit of work. 
>> Order is important, especially if interrelational dependencies exist.
>>
>>
>>>Most DBMS include the ability to rollback complete transactions
>>>when an error is detected.
>>>...
>

> (Geez, I wish people would snip out the parts of the OP that they aren't
> replying to.)

>

I'll keep that in mind.

> Anyway, at the risk of being too long-winded, I must say that I object to
> definitions that imply how a phenomenon such as transactions must be
> implemented, even though I realize that many people these days don't
> consider a "definition" to be a definition unless it tells them what to
> do.

>

I'm not sure I understand your objection. I was just trying to point out that a set of operations evaluated in one order may produce a different result than the same set of operations evaluated in another. If the order is specified, then there's no question which result was desired.

> The definition I remember, came, I think, from Jim Gray, twenty or more
> years ago. Even though I also object to much of his approaches, I liked
> how he described a transaction. Quoting from memory since I don't his
> book of papers anymore, it went something like "a transaction transforms a
> database from one consistent state to another consistent state". I don't
> much like the word "state" anymore as it seems a little ornamental when
> "value" says all that needs to be said and carries fewer connotations with
> it.

>

"State" adds a temporal connotation and is thus more precise than "value" when discussing an pair of values separated in time by an event. "State" also implies that there's a method behind the madness, making it better still and also better than "instance" in this instance.

> I have a hard time running with any definition that talks of "logical unit
> of work", having grown up with various IBM propaganda that used "LUW"
> acronyms and to get down to brass tacks, just what that "unit" could be is
> usually dictated by some implemented language.

>

> Being hair-challenged myself, I feel a little guilty when I refer so often
> to TTM 2nd Ed, chapter four (I gather it is appendix A in the third
> edition) as I have the feeling that some readers pull out their own hair
> trying to read my posts! I'll say what I like about it - IMHO, it is the
> most genuine attempt at laying down a precise context for talking about
> RT. It is concise too. In these days when free speech encompasses free
> jargon, it is the kind of basis that helps me think that I can see what
> people are talking about in actuality. (That's why when I get on my
> high-horse when I see SQL keywords such as "CASCADES" get used rather
> casually whereas I think they need to be discussed if only to make sure
> that everybody has a common understanding of them.)

>

> Getting back to transactions, I feel their definition (whatever it is) has
> been muddied or even polluted by various phenomena that aren't mentioned
> in the above: concurrency, persistence and implementation devices such as
> triggers. To use a 1960's/1970's phrase, I think the basic notion has
> today come to involve a tremendous amount of bio-feedback. I would like
> to see a definition of transaction that is expressed in terms of results,
> not mechanisms. The way I would approach it would be to cut those
> phenomena out and try to express it solely in terms of how a single user,
> single process, single thread application system would re-iterate
> constraints that gave the same consistent results. Eg., one where
> everytime an app is required to pretend that other processes are locked
> out by repeating its own results to that point, for the approval of the
> system. Of course, a dbms wouldn't be implemented to do that
> parrot-style, but it would be a definition that an imp could be validated
> against.

>

I'm not really sure I understand what you're trying to say here. I would like to see a definition of transaction that is expressed in terms of what is different between successive database states. If you focus on results, some of the information submitted by the user is lost in translation. That's why I get a bad taste in my mouth when I see the imperatives insert, update, and delete translated into assignment.

> p
Received on Wed Apr 18 2007 - 00:27:05 CDT