Re: cdt glossary 0.1.1 (repost)

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.

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

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.

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.

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.

p Received on Wed Apr 18 2007 - 05:40:43 CEST