Re: cdt glossary 0.1.1 [Transaction]
Date: Thu, 19 Apr 2007 01:40:05 +0200
Message-ID: <4626aba7$0$333$e4fe514c_at_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 Thu Apr 19 2007 - 01:40:05 CEST