Talk:Serializability

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)

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)

---

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)

Disambiguation for serializable has been added Comps 02:59, 17 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..."

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)

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)

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)

A new SI related method, Serializable snapshot isolation, which is relevant to the article, has been added. -- Comps (talk) 18:40, 21 September 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)

See Talk:Global serializability#Are the experts experts?

for additional discussion relating to Commitment ordering. - JCLately (talk) 16:54, 20 May 2008 (UTC) Comps (talk) 14:44, 10 August 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)

Craig,

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)

Craig, Pls respond to my comments above. Thanks. --Comps (talk) 12:54, 24 February 2011 (UTC)

As I wrote above, 3-4 paragraphs for a >30,000 article is acceptable, so I do not quite see the problem that justifies the tag. Tag removed. --Comps (talk) 14:17, 2 March 2011 (UTC)

Commitment ordering

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)

Reason For Redirect

Redirect because this topic is better explained in the "Database transaction schedule" article. This article was started by "https://wiki.riteme.site/wiki/User:Comps" who has been known to make articles nearly impossible to edit and read, and commonly wrote incorrect information (see https://wiki.riteme.site/wiki/Commitment_ordering). This author also has created sockpuppets (e.g., User:Yoav Raz). The outline for this article is poorly structured. The article that is linked is a superset of this article (but does not include much more information than this article). Jarfuls of Tweed (talk) 03:29, 5 March 2024 (UTC)

I'm not opposed to deleting dubious content and replacing them with better-written ones, but I think blanking a page is way too drastic. At least there is a paragraph or two of content that is worth preserving? I saw that you already moved content from other articles to this article, so presumably there's some good content here. I don't think Wikipedia's policies are in support of blanking a page merely because it's created by a problematic user and is a subset of another article. See WP:BLANKANDREDIRECT and WP:BLANK. In particular, WP:ATD stipulated that

If an article on a notable topic severely fails the verifiability or neutral point of view policies, it may be reduced to a stub, or completely deleted by consensus at Wikipedia:Articles for Deletion.

Personally, I would much rather some part of the content remain in this article (even just a paragraph) so that other people can help improve it. As long as we leave correct information on this page, people would not be misled. PetraMagna (talk) 06:16, 5 March 2024 (UTC)

I just looked around at the edits of User:ERfan111 and User:Comps. I'm surprised that some of them are still lingering on this project and no one has cleaned them up. Commitment ordering is indeed an abomination of an article and it's sad that a previous AFD did not delete it. I think CO is the article that should be blanked and redirected, deleted, or turned into a stub. Serializability is on the other hand much more salvageable. PetraMagna (talk) 06:50, 5 March 2024 (UTC)

I also think that explaining serializability from the Database transaction schedule article is much easier due to the concepts reliance on a the concept of a database schedule. Additionally, the majority of the information in Database transaction schedule is about serializability, and the information that is not about serializability, is heavily intertwined with its concepts, especially the diagram at the back. It is extremely nice starting the concept of a Serial schedule before explaining serializability, as done in Database transaction schedule, but it would be awkward to do that in this "Serializability" article given that it should start with the concept of serializability. I just think the explanation of concepts would be less concise and more clunky if we division them up into separate articles. Jarfuls of Tweed (talk) 07:11, 5 March 2024 (UTC)

It might be hard to explain a particular concept because it has another concept as a prerequisite, but this shouldn't be a hindrance for it to be its own article, especially for a concept that definitely satisfies WP:V. The Raz issue is in my opinion more important than this discussion, though, so I can put this off for a bit. I might try to rewrite the article based on a textbook later. PetraMagna (talk) 07:45, 5 March 2024 (UTC)