Talk:Serializability

From Wikipedia, the free encyclopedia

 This article is within the scope of WikiProject Databases.
B rated as B-Class on the assessment scale
Top rated as Top-importance on the assessment scale

Contents

[edit] Classification changed

Classification changed to B-class and Top-importance. Serializability is the major criterion of correctness for concurrent transactions, and supported in all general purpose databases. It is a long-time, mature database research area. The article provides all the background and essentials regarding Serializability, and well references other relevant articles, categories, and external sources. - Comps (talk) 20:21, 7 February 2008 (UTC) - Comps (talk) 20:27, 7 February 2008 (UTC)

[edit] Cleanup tag

User 129.241.138.154 has put a cleanup tag without any concrete suggestions. I shall remove the tag in few days unless this user comes with concrete suggestions for cleanup. User: Comps May 31 2006

Clean-up tag removed Comps 15:44, 4 June 2006 (UTC)

[edit] Correctness of sentence in View serializability and Conflict serializability

Currently the View serializability and Conflict serializability section of this article ends with:

"A more general definition of conflicting operations (also for complex operations, which may consist each of several "simple" read/write operations) requires that they are noncommutative (changing their order also changes their combined result). For example, the operations increment and decrement of a counter are both write operations, but do not need to be considered conflicting since they are commutative."

Is the final sentence correct? It seems to be assuming that increment and decrement are atomic, but I don't think this can be assumed in general. My memory is somewhat hazy regarding conflict serialisability though so I haven't changed it. AlyM 13:48, 8 August 2006 (UTC)

You are right. It is assumed, but still, the sentence is correct. It should be supported by the system as atomic primitives, if such a broadening of conflicts is allowed. I'll add a comment. You are welcome to change, of course. Thanks. Comps 01:25, 15 August 2006 (UTC)

Answer above slightly augmented. Comps 12:45, 11 September 2006 (UTC)

[edit] Redirection from "Serializable (databases)" has been added.

Disambiguation from "Serializable (programming)" may be desirable, since Java and .NET use this term. Comps 14:39, 13 March 2007 (UTC)

Disambiguation for serializable has been added Comps 02:59, 17 March 2007 (UTC)

[edit] Comments on the references

“Transactional Information Systems” is most likely the most current book on the subject. It is very detailed and thorough. However I was surprised to see the section on Commitment Ordering: It is poor at best. It seems that the authors completely did not understand the original papers, though they cite them in the book. They seem to follow the papers on Strong Recoverability that do not have much more than a definition of the term. Lack of understanding there of what recoverability is is clear. It is suggested the authors read the Wikipedia article on Commitment Ordering. They need to rewrite this section.

"Concurrency control..." of Bernstein et al is a little dated and not completely clean of errors, but almost "classic..."

Both are appropriate references. —The preceding unsigned comment was added by 72.195.135.30 (talk • contribs) 23:36, June 14, 2007 (UTC)

  • None is perfect... Comps 12:54, 16 June 2007 (UTC)

Commitment ordering reference has been added to the article for self-containment. Though not a textbook, the reference has been added due to the very partial and inaccurate coverage of CO in Vossen and Weikum (2001). Bernstein et al (1987) is older than CO. Comps (talk) 15:01, 23 December 2007 (UTC)

[edit] Cleaned up

Hi, as I've just found and read the whole article, I couldn't resist the urge to quickly fix it. The content is excellent but the form I found to be unreadable. Too many awkward conventions not coherent with WP:MOS. Comps, I hope my "fresh look" edit helps you... --Kubanczyk 19:39, 31 July 2007 (UTC)

  • Thank you for the clean-up. While I like very much your text improvments (except some inaccuracies that I noticed, e.g., when should be "if and only if"), the new section structure is unacceptable: Testing is NOT enforcing, and Global serializability is a whole different issue from Local serializability and deserves a separate section. Thus I revert to last Comps. I'll insert your text in the old structure in time. Comps 17:17, 1 August 2007 (UTC)
  • The current structure is unacceptable to me, but in a second thought it may be easier to make corrections in your version. Comps 17:27, 1 August 2007 (UTC)
  • Many thanks! Text was improved significantly. Was instructive. Comps 20:05, 1 August 2007 (UTC)
Glad to see that. Personally I hate it too when others edit my work ;) --Kubanczyk 20:14, 1 August 2007 (UTC)
Hate (well, no need to be so extreme...) at first sight (only). Later loved it. Comps 20:31, 1 August 2007 (UTC)
Better watch out. Would you also love the profanation of Commitment ordering and Global serializability? :))) --Kubanczyk 20:59, 1 August 2007 (UTC) Joking! My "editor" mood is a scarce one.
Thanks. This was my first experience with such massive editing, and I have some comments in retrospect. Though I thought in the begining that it would be quite an easy fix, to bring it back to a satisfactory article from my point of view, it was not... I failed to anticipate that text accumulated carefully for 18 months or so would take some time to check thoroughly after a massive change... This in spite of the relative simplicity of Serializability, in comparison to Commitment ordering, for example. I do not think I could manage such overall change for Commitment ordering. Some conclution:
  • Changes should be done incrementally, section by section at a time.
  • Article structural changes should be left to the last step, to allow following the dif files without mixing texts of different sections, which makes it impossible.
  • Info (text) should not be dropped, even if looks redundant. The author may have specific intention in it.
In summary, the end result is very satisfactory: better readable text, and size drop in 1000. I believe I have filled most of the gaps. Thanks again. -- Comps 01:41, 2 August 2007 (UTC)
Two last comments and I'm walking away... (1) You are very careful about your article. (2) In general any knowledge transfer between human beings (such as wikipedia) is all about dropping info, and a lot of it. Sometimes even important-looking info, this is a pain. But this is only my personal opinion. --Kubanczyk 10:30, 2 August 2007 (UTC)
Well, I do not want you walk away. Comps 15:20, 2 August 2007 (UTC)
Cheer up, wikipedia is all about walking away :) I come with a fresh head, read the story, edit, walk away. No point to stay, because I've just lost a fresh look and any further edits will be worse. For the same reason I cannot stage edits like you've proposed. Nara :)) --Kubanczyk 21:06, 2 August 2007 (UTC)
I see your point. Take care. Comps 06:34, 3 August 2007 (UTC)
Oops, misunderstood you above. BTW, agree with your comment 1. With 2. I agree with the following interpretation: Sometimes drop=remove, sometime drop=bring_new... Comps 18:58, 3 August 2007 (UTC)