In hook user presave I implemented thread safe logic, based on Locker service.

// Thread safe locking for ensuring correct user id.
      while (!$this->lockBackend->acquire(static::LOCK)) {
        // Wait 0.1 second for next attempt.
        $this->lockBackend->wait(static::LOCK, 0.1);
      }
      // Use try/finally to guarantee lock release.
      try {
        // Lock acquired.
       ... some logic
      }
      finally {
        // Release lock.
        $this->lockBackend->release(static::LOCK);
      }

I wrote simple web test for this that emulates concurrent threads for user creration:

$users = User::loadMultiple();
// 2 users already
$this->assertCount(2, $users, "User count is 2");
$i = 0;
$usersCount = 5;
$requests = [];
while ($i < $usersCount) {
// drupal get async is custom method, based on built in httpClient.
// path '/consistent_uid_test/user_create_handler' handler creates user.
$requests[] = $this->drupalGetAsync('/consistent_uid_test/user_create_handler/' . $this->getRandomGenerator()->name(8, TRUE) . '/' . sha1('keep_calm_dude'));
$i++;
}
\GuzzleHttp\Promise\all($requests)->wait();
$users = User::loadMultiple();
$this->assertCount($usersCount + 2, $users, "User count is {$usersCount}");

so SOMETIMES this success and sometimes:

there is an exception: Drupal\Core\Entity\EntityStorageException: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: INSERT INTO {semaphore} (name, value, expire) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array
(
[:db_insert_placeholder_0] => consistent_uid.lock
[:db_insert_placeholder_1] => 4243437945b68c6bb5f5827.54321271
[:db_insert_placeholder_2] => 1533593305.3904
)
in .....

As i see there is no special handling for this kind of exception in locker class. And this is not documented and breaks all locking logic.

Is locking system safe?

Comments

olexyy.mails@gmail.com’s picture

Issue summary: View changes
cilefen’s picture

Priority: Major » Normal
olexyy.mails@gmail.com’s picture

Looks like simple wrappers done work for this load test. Switched to 100 parallel threads.
All this does is simply repeat attempt on deadlock. All is according to MySQL docs =)))).

 /**
   * Attempts to handle deadlocks.
   */
  public function acquireLock() {

    $acquired = FALSE;
    while (!$acquired) {
      try {
        while (!($acquired = $this->lockBackend->acquire(static::LOCK))) {
          $this->lockBackend->wait(static::LOCK);
        }
      } catch (\Exception $e) { }
    }
  }

  /**
   * Attempts to handle deadlocks.
   */
  public function releaseLock() {

    $released = FALSE;
    while (!$released) {
      try {
        $this->lockBackend->release(static::LOCK);
        $released = TRUE;
      } catch (\Exception $e) { }
    }
  }

Set $usersCount = 100;
We need to understand that this emulates 100 parallel threads to one server with each requesting user creation.
As test case forms queue of 100 requests, and method Guzzle wait() executes them all at once.

olexyy.mails@gmail.com’s picture

See consistent_uid module for details.

Very weird that locking system does not pass high load tests by default.

olexyy.mails@gmail.com’s picture

Priority: Normal » Minor
olexyy.mails@gmail.com’s picture

Issue summary: View changes

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

luke.stewart’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +Bug Smash Initiative, +Needs issue summary update

This has sat untouched for a while. It's now the daily target for the Bug Smash Initiative.

I'm marking PMNMI, and Needs Issue Summary Update.

I think this issue requires a clearer statement of the problem, and an updated issue summary to reflect that. Otherwise this can probably be closed in 3 months.