hoo added a comment.

  In T44325#6976484 <https://phabricator.wikimedia.org/T44325#6976484>, 
@Addshore wrote:
  
  > So assuming we are looking at the immediate time after item creation, and 
before the sitelinks enter the secondary index, we could add an extra layer of 
checks for this specific case.
  > This could for example be storing newly created item sitelinks in memcached 
for a short period of time (covering the time before they will be in the sql 
index).
  > This would then also be checked when new sitelinks are added.
  
  I had a similar idea, but I think just using the object cache is not going to 
entirely solve this (as we can't truly get an exclusive lock) also solely using 
`IDatabase::lock` might not work reliably (as those get dropped if the 
connection is closed). The following should work though:
  
  Entity creation:
  
    foreach ( $sitelink in $sitelinks ) {
        if ( IDatabase::lock( $sitelink ) && !BagOStuff::get( $sitelink ) ) {
                BagOStuff::set( $sitelink, true, 1234 );
        } else {
                // give up and clean up
        }
    }
    
    // release all IDatabase::lock locks (automatically happens once the 
connection closes)
  
  When writing the sitelinks we can now simply remove the BagOStuff cache 
entries.
  
  This poses a potential problem that all requests creating an entity at once 
might fail (as no single request might manage to get all locks), but I guess 
this is pretty pathological and not going to happen much.
  The more relevant problem is probably going to be, we (successfully) claim 
all sitelinks, but then never actually commit them to the table (as the edit 
fails for some reason). We might be able to mitigate this by only placing the 
locks after all/most other checks are done (thus we can be sure the edit is 
going through).

TASK DETAIL
  https://phabricator.wikimedia.org/T44325

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: hoo
Cc: M2k_dewiki, Mohammed_Sadat_WMDE, DannyS712, Mike_Peel, Lea_Lacroix_WMDE, 
Takasugi_Shinji, VIGNERON, alaa_wmde, Robby, Stashbot, Addshore, Nikki, 
Liuxinyu970226, aude, Aklapper, AnjaJentzsch, Abraham, jeblad, Legoktm, He7d3r, 
Merl, jayvdb, Denny, revi, matej_suchanek, Lydia_Pintscher, Beta16, daniel, 
hoo, Invadibot, maantietaja, Muchiri124, CBogen, Akuckartz, Nandana, lucamauri, 
Lahi, Gq86, Ramsey-WMF, GoranSMilovanovic, QZanden, LawExplorer, Poyekhali, 
_jensen, rosalieper, Taiwania_Justo, Scott_WUaS, Jonas, Ixocactus, Wong128hk, 
Wikidata-bugs, El_Grafo, Dinoguy1000, Steinsplitter, Mbch331, Keegan
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to