Last modified: 2013-12-13 23:11:20 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T42375, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 40375 - Transaction warning: WikiPage::doDeleteArticleReal
Transaction warning: WikiPage::doDeleteArticleReal
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
1.20.x
All All
: Unprioritized normal (vote)
: ---
Assigned To: Daniel Kinzler
:
Depends on:
Blocks: 39480
  Show dependency treegraph
 
Reported: 2012-09-20 05:50 UTC by Niklas Laxström
Modified: 2013-12-13 23:11 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Niklas Laxström 2012-09-20 05:50:42 UTC
WikiPage::doDeleteArticleReal: Transaction already in progress (from DatabaseBase::query (LinkCache::addLinkObj)),  performing implicit commit! [Called from DatabaseBase::begin in /www/translatewiki.net/w/includes/db/Database.php at line 2888] in /www/translatewiki.net/w/includes/debug/Debug.php on line 282
Comment 1 Daniel Kinzler 2012-09-22 10:14:18 UTC
Ugh, that's bad - the old transaction is broken by a pre-mature commit, causing as race condition. This really needs fixing :(

I didn't dig into the code, but it seems pretty odd to me that doDeleteArticleReal would be called while a transaction started by LinkCache::addLinkObj is still in progress.
Comment 2 Alexandre Emsenhuber [IAlex] 2012-09-22 17:56:54 UTC
Remember that LinkCache::addLinkObj() does not start a transaction by itself, it is DatabaseBase::query() that starts it when there's no transaction running.
Comment 3 Daniel Kinzler 2012-09-22 19:40:59 UTC
DatabaseBase::query() unilaterally starts a transaction? Without any control over when or how that transaction gets committed? is that the mysterious DBO_TRX stuff that Aaron was talking about? This scares me...

To me, transactions should always be opened and closed in the same scope, or at least in the same class... any automatism is bound to break the symmetry, silently causing race conditions and inconsistencies...
Comment 4 Aaron Schulz 2012-09-22 19:55:33 UTC
If DBO_TRX is set (which it is for sapi mode), and query() called, and there is no transaction, it will start one first. If already in a transaction, it won't call BEGIN.

This sucks in that web requests are normally wrapped in nice ACID transactions (except when broken by manual begin() calls) but cli scripts don't use transactions unless code has explicit begins.

So code with:
$dbw=wfGetDB(DB_MASTER);
$dbw->insert(...);
$dbw->update(...);
...is atomic for web requests, but not for cli scripts (like job runners).

The whole system is kind of a cluster fsck. I'm trying to avoid this stuff in my RDBStore patches...
Comment 5 Aaron Schulz 2012-10-29 22:31:00 UTC
These notices have been fixed by now (in the trx warning saga).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links