Re: cdt glossary 0.1.1 [Transaction]

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Thu, 19 Apr 2007 01:40:05 +0200
Message-ID: <4626aba7$0$333$e4fe514c@news.xs4all.nl>

Brian Selzer wrote:

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

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

>
> I'll keep that in mind.

Thanks.

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

Hi Brian, yes, I didn't say that yet: I agree with you that the order (so /no/ set!) is of the utmost relevance for transactions. How to capture this in a definition that can be agreed upon in a knowledgeable group (like this - I hope) is another matter.

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

I take it you are well versed in STN. Somehow this is outside the realm of interest of most database practitioners. Received on Wed Apr 18 2007 - 18:40:05 CDT