https://bugzilla.wikimedia.org/show_bug.cgi?id=37225
--- Comment #63 from christ...@quelltextlich.at 2012-07-11 17:53:28 UTC --- Seems Aaron provided a hotfix while I prepared the logs for uploading in the previous comments :D But towards his order of a "more ideal solution" ... it seems the culprit is the usage of "FOR UPDATE" in (only) some of the relevant queries. So some queries see values updated by other transactions, while other queries do not. Assume we want to edit a page PageZ that is at revision 5. Both B and C are each about to submit a new revision. B submits first, and opens a master (say BM) and a slave (say BS) connection to the database. Both connections are on a transaction. For both BM and BS, the page's page_latest is obviously 5, and the highest rev_id in the revision table for the page is obviously 5 as well. /Before/ B's loadPageData executes the sql of EditPage.php:1206 $this->mArticle->loadPageData( 'forupdate' ); C starts submitting her revision. So C also opens a master (say CM) and a slave (say CS) connection to the database. Both connections are on a transaction as well. For both CM and CS, the page's page_latest is obviously 5, and the highest rev_id in the revision table for the page is obviously 5 as well. Now while B's request is handled slowly, C's request zooms right through. C's revision gets added (using rev_id 6) on CM for the page. For BM, BS, and CS, the pages page_latest is still 5, while for CM it is 6. Accordingly for the page's highest rev_id. C's request is done. The transactions CM and CS are committed. Now B's request reaches the SQL for EditPage.php:1206 $this->mArticle->loadPageData( 'forupdate' ); . This SQL statement (for connection BM) is SELECT /* WikiPage::pageData Root */ page_id,page_namespace,page_title,page_restrictions,page_counter, page_is_redirect,page_is_new,page_random,page_touched,page_latest,page_len FROM `page` WHERE page_namespace = '0' AND page_title = 'PageZ' LIMIT 1 FOR UPDATE Although the page's page_latest has been 5 before for BM, this query now yields a page_latest of 6, due to the "FOR UPDATE" suffix. But recall that for both BM and BS the page's page_latest is still 5 without "FOR UPDATE", just as their highest rev_id in the revision table for the page is also still at 5. So the subsequent Revision::fetchFromConds on BS (with "rev_id = '6'") fails. Also the subsequent Revision::fetchFromConds on BM (with "rev_id ='6'") fails. Should we: - just stick with the hotfix of exception throwing, - restart our transaction to be able to fetch revs that have been committed after our transaction started, - add more "FOR UPDATE"s to be able to fetch revs that have been committed after our transaction started, - get rid of the "FOR UPDATE"s and detect an edit conflict, or - something completely different? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
