Re: cdt glossary 0.1.1 [Transaction]

paul c wrote:
> Brian Selzer wrote:

>> You need to correct the entry for Transaction.  See below.
>>
>> mAsterdam wrote:
>> ...
>>> [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.
>>> ...

Amen. (No I am not a Christian - for BB: not Islamic either).

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

Hi paulc, sorry, I only have the first edition.

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

To ambitious for the glossary.

paulc, please don't get me wrong. Received on Thu Apr 19 2007 - 01:29:02 CEST