|WikiProject Databases / Computer science||(Rated B-class, High-importance)|
|WikiProject Computer science||(Rated B-class, High-importance)|
- 1 Classification changed
- 2 Cleanup tag
- 3 Correctness of sentence in View serializability and Conflict serializability
- 4 Redirection from "Serializable (databases)" has been added.
- 5 Comments on the references
- 6 Cleaned up
- 7 all general purpose database systems?
- 8 Automatic global deadlock resolution in SS2PL - Unnoticed for three decades?
- 9 See Talk:Global serializability#Are the experts experts?
- 10 Tag - Introduction may be too long
- 11 Commitment ordering
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)
User 188.8.131.52 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)
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)
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)
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..."
- 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)
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)
- 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)
- 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)
all general purpose database systems?
Note the list of databases which instead support snapshot isolation as their highest degree of transaction isolation in the Snapshot isolation article. In some cases, a request for a transaction with a serializable transaction isolation level actually provides a transaction with at the snapshot transaction isolation level. I think the Serializability article should recognize the absence of support for this feature in many general purpose database systems, and reference the Snapshot isolation article. Validar (talk) 22:40, 6 January 2009 (UTC)
In short, yes, all general purpose database systems. Could you imagine a database system vendor selling one that cannot do accounting and many other applications? Comps (talk) 15:38, 31 January 2009 (UTC)
Indeed some database systems use the term serializable for snapshot isolation, which is misleading given the earlier history of "serializable" and the fact that these two are different isolation levels. An unfortunate naming, probably originally resulting from a misunderstanding due to similarity in several aspects, and then becoming a "standard" for multi version. In this sense these database systems do not transparently support serializability for multi versioning. However serializability can be enforced by the user (transaction programmer) when needed by using known methods, and thus it is actually supported. Already several articles have been written about this subject. For example, Making Snapshot Isolation Serializable by Fekete et al, ACM TODS, June 2005. It is also discussed in Snapshot isolation. Thus I do not see a place for this in the Serializability article: It is something different called (mistakenly, no doubt) by the same name. However it is worthwhile adding this in the disambiguation of Serializable, so people are aware of the difference in meaning when the isolation level "serializable" is discussed in the context of these database systems, and the need to take special measures when real serializability is required. Comps (talk) 07:33, 31 January 2009 (UTC)
Automatic global deadlock resolution in SS2PL - Unnoticed for three decades?
Both practitioners and researchers have dealt with global (and distributed) deadlocks in SS2PL based systems for decades. Many research papers have been written about the subject and its resolution, but none (except the Commitment ordering papers) is known to notice the automatic resolution by 2PC. It is unclear how for so long the statistics of implemented special resolution mechanisms, showing no use, or almost no use, have not attracted people's attention to this fact. A case where the automatic solution suffered from long delays and kicked in the dedicated mechanisms may be one explanation. Maybe resolution of a global deadlock by aborts by faster (than 2PC's) local timeouts gave a satisfactory explanation to observers, and a smoke-screen. Any other explanation? -- Comps (talk) 18:00, 9 July 2009 (UTC)
Tag - Introduction may be too long
05:47, 21 February 2011 Craig Pemberton (talk | contribs) (55,512 bytes) (lead should be clearer and shorter see WP:LEAD) (undo)
The lead should give a fair short summary of the article. If too short it misses its purpose. In your Wiki links (in the tag) 3-4 paragraphs for a >30,000 article is acceptable, so I do not quite see the problem that justifies the tag. Please remove the tag.
This article has been evolved for almost five years. It is within a specialized mathematical area though an effort has been made to use English only rather than Math symbols. I find every word and sentence important, unlike other, non-mathematical texts, where you may have more latitude. It may be improved, but please do not cut text in a way that changes meaning. You ended with changing, e.g., to "serializability of a transaction" which does not have any meaning within existing concurrency control, and thus really harms the article. If you are not an expert (and clearly you are not), please do not change meaning (which clearly was not your intention, but you failed). --Comps (talk) 13:49, 22 February 2011 (UTC)
The neutrality of part of this page is disputed, as part of a wider discussion. See Talk:Commitment ordering and Wikipedia talk:WikiProject Computer science#User:Comps / Commitment ordering. —Ruud 14:33, 23 December 2011 (UTC)