Page MenuHomePhabricator

Transaction warning: EditPage::commitWatch (SMWStore::updateData)
Closed, ResolvedPublic

Description

PHP Notice: EditPage::commitWatch: Transaction already in progress (from DatabaseBase::query (SMWStore::updateData)), 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


Version: master
Severity: normal

Details

Reference
bz40377

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:01 AM
bzimport set Reference to bz40377.
bzimport added a subscriber: Unknown Object (MLST).

I suspect a bug in SMW is causing this, changing the component accordingly.

This is the remaining high-flood notice from the transaction debugging which is preventing us from restoring IRC relay.

Of last 1000 lines of error log there are 686 instances of this warning.

If SMWStore::updateData calls EditPage::commitWatch from within a transaction, that needs to be fixed. I'm not familiar enough with SMW to have an opinion on how to best do this. I guess the new onTransactionIdle function in Database could help, ask Aaron about it.

I cannot find any occurrence of "commitWatch" in SMW on master.

Nike, can you provide a full stack trace?

After looking through the code with jeroen, I guess what is happening is this:

SMWStore::updateData calls Database::update, which starts an automatic transaction (because of DBO_TRX) and marks it as having done write operations. Then, some time later, EditPage::commitWatch tries to explicitely starts a transaction, which triggers the warning.

It seems that the idea of warning about automatically committing transactions if they have done write operations does not solve our problem. We have to either disable the warnings completely if DBO_TRX is enabled, or at least disable them for implicit transactions that were started because of DBO_TRX. trxLevel = -1 could be used for that - a bit hackish, but should work.

Aaron, what do you think?

That would remove almost all of the value of the warnings. If there is no way to fix the too many transactions we can always but the warnings behind $wgDebugDBTransactions exclusively if nothing else. But I would like them to show up with "developer warnings" enabled if possble.

See https://gerrit.wikimedia.org/r/26409.

Aaron: I like the onTransactionIdle stuff you added, and it could be used here, if you introduced in MW 1.17 :) We'll have to wait a bit before we can require 1.20 (which isn't even released at this point).

Please do add @since tags to such new methods, I had to do a git blame and check the 1.19.0 rel.

This should be added in a BC way, because this is a must-have. Logs on twn are being swamped by this issue.

Siebrand: you can presumably get rid of the log issue by setting $smwgAutoRefreshSubject to false. Obviously this does not actually fix the warning issue though...

These notices have been fixed by now (in the trx warning saga).