Last modified: 2012-03-30 00:23:13 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 T37357, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 35357 - LCStore is not handling transactions correctly
LCStore is not handling transactions correctly
Status: NEW
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
unspecified
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-20 15:37 UTC by Mark A. Hershberger
Modified: 2012-03-30 00:23 UTC (History)
5 users (show)

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


Attachments

Description Mark A. Hershberger 2012-03-20 15:37:30 UTC
Broken off from Bug 27383 comment 13

Another problems happens once right at the beginning of every import:

 BEGIN
   SELECT -- LCStore_DB::get
*  BEGIN  -- fails
   DELETE -- LCStore_DB::startWrite
   INSERT -- LCStore_DB::set
...

(In reply to comment #11)
> Are you getting
> 
> Transaction state changed from 
> 
> in the debug log?

Attaching the bit of the log that covers this section above.
Comment 1 Platonides 2012-03-20 21:21:52 UTC
Why does it issue the first get() ?
Comment 2 Mark A. Hershberger 2012-03-21 02:44:57 UTC
(In reply to comment #0)
> Broken off from Bug 27383 comment 13

Um... that should be Bug 27283 comment 13
Comment 3 Mark A. Hershberger 2012-03-21 02:51:25 UTC
(In reply to comment #1)
> Why does it issue the first get() ?

Looking at the debug log (http://bug-attachment.wikimedia.org/attachment.cgi?id=10274), this is what is shows:

Query my_wiki (15) (slave): BEGIN
Transaction state changed from IDLE -> TRANS
Query my_wiki (16) (slave): SELECT /* LCStore_DB::get 127.0.0.1 */  lc_value  FROM "l10n_cache"  WHERE lc_lang = 'en' AND lc_key = 'deps'  LIMIT 1  
Query my_wiki (17) (slave): SELECT /* LCStore_DB::get 127.0.0.1 */  lc_value  FROM "l10n_cache"  WHERE lc_lang = 'en' AND lc_key = 'list'  LIMIT 1  
Query my_wiki (18) (slave): SELECT /* LCStore_DB::get 127.0.0.1 */  lc_value  FROM "l10n_cache"  WHERE lc_lang = 'en' AND lc_key = 'preload'  LIMIT 1  
LocalisationCache::isExpired(en): cache missing, need to make one
LocalisationCache::recache: got localisation for en from source
Comment 4 Marcin Cieślak 2012-03-30 00:23:13 UTC
From https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=includes/LocalisationCache.php;h=a50bf0d8a8eed739b78ff401f70d24246b6da024;hb=a358f21ffe39ce7c76a27300aa8002108399d331#l912

 910                 $this->dbw = wfGetDB( DB_MASTER );
 911                 try {
 912                         $this->dbw->begin( __METHOD__ );
 913                         $this->dbw->delete( 'l10n_cache', array( 'lc_lang' => $code ), __METHOD__ );
 914                 } catch ( DBQueryError $e ) {
 915                         if ( $this->dbw->wasReadOnlyError() ) {
 916                                 $this->readOnly = true;
 917                                 $this->dbw->rollback( __METHOD__ );
 918                                 $this->dbw->ignoreErrors( false );
 919                                 return;
 920                         } else {
 921                                 throw $e;
 922                         }
 923                 }

Yes, we try to open a new transaction (this begin will be a no-op on PostgreSQL
if and there is nothing committed at the end. I don't really understand why it is necessary to have manual transaction control here. MySQL deadlocks?

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


Navigation
Links