[REF] Slightly more logical order of code

Just moves the lock check to the same area

diff --git a/CRM/Contact/BAO/GroupContactCache.php b/CRM/Contact/BAO/GroupContactCache.php
index 643f206eff862d22c666b1f4bbf6fd349f67a9c7..229f54c8af63ee0267c6f5a6a7c45e4597dda0c4 100644 (file)
--- a/CRM/Contact/BAO/GroupContactCache.php
+++ b/CRM/Contact/BAO/GroupContactCache.php
@@ -383,13 +383,6 @@ WHERE  id IN ( $groupIDs )
 
     // grab a lock so other processes don't compete and do the same query
     $lock = Civi::lockManager()->acquire("data.core.group.{$groupID}");
-
-    $groupContactsTempTable = CRM_Utils_SQL_TempTable::build()
-      ->setCategory('gccache')
-      ->setMemory();
-    self::buildGroupContactTempTable([$groupID], $groupContactsTempTable);
-    $tempTable = $groupContactsTempTable->getName();
-
     if (!$lock->isAcquired()) {
       // this can cause inconsistent results since we don't know if the other process
       // will fill up the cache before our calling routine needs it.
@@ -398,6 +391,12 @@ WHERE  id IN ( $groupIDs )
       return;
     }
 
+    $groupContactsTempTable = CRM_Utils_SQL_TempTable::build()
+      ->setCategory('gccache')
+      ->setMemory();
+    self::buildGroupContactTempTable([$groupID], $groupContactsTempTable);
+    $tempTable = $groupContactsTempTable->getName();
+
     // Don't call clearGroupContactCache as we don't want to clear the cache dates
     // The will get updated by updateCacheTime() below and not clearing the dates reduces
     // the chance that loadAll() will try and rebuild at the same time.