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.

Remember that LinkCache::addLinkObj() does not start a transaction by itself, it is DatabaseBase::query() that starts it when there's no transaction running.

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...

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...

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