Publish all changes within a database transaction to allow rollbacks

UPDATE:
After I wrote most of what's below I thought, maybe I am overthinking it. Hopefully when we use Workspaces, our "publishing" will just be moving entity revision to another Workspace, and we can rely on Workspaces for handling transactions. If that is the case maybe we could just surround the current code in a transaction.

but I wonder if one quick improvement to make a deadlock in the tempstore less like would be to introduce \Drupal\experience_builder\AutoSave\AutoSaveManager::deleteAll() which would call a new \Drupal\experience_builder\AutoSave\AutoSaveTempStore::deleteAll and then that would call the existing \Drupal\Core\KeyValueStore\KeyValueStoreInterface::deleteAll()

I don't know that much about tempstore deadlocks but it seems like this \Drupal\Core\KeyValueStore\DatabaseStorage::deleteAll is 1 db operation so hopefully that would decrease our chances of deadlocks

Original, maybe overthinking🤔

I think this is good idea but also I wondering if there are thing we could do to make a deadlock more unlikely

However, there more may likely be deadlocks on the temp store when deleting the autosave.

Could we avoid this by making sure our tempstore is not read during the publish process?

For instance since currently you can't select which items you will publish, you have to "Publish all", could we stop the XB UI from working once the "Publish all" process is started. Nobody should really be making changes once you click "Publish all". Before we start saving the entities we have already loaded the auto-save states, $this->autoSaveManager->getAllAutoSaveList() , into memory so there is not chance new changes will affect the entity saves but another user using the XB UI would have no way of knowing that.

Maybe something like this

try {
$this->connection->startTransaction();
$this->autoSaveManager->lock();
foreach ($entities as $entity) {
    $entity->save();
}
$this->autoSaveManager->deleteAll();
}
catch(Exception $e){
   if (isset($transaction)) {
        $transaction->rollBack();
      }
      Error::logException($this->logger, $e);
      throw $e;
}

Then maybe the controllers that interact with the AutoSaveManager could do something like this at the start

if ($this->autoSaveManager->isLocked()) {
  throw new Exception('Experience is currently publishing.....');
}

We could put this a trait method, ensureNotPublishing().

Otherwise I don't think there is anything currently stopping somebody from continue to make XB changes while another user has just clicked "Publish all"

#3: very good point this may become obsolete.

we can rely on Workspaces for handling transactions

If this is true: is there a test we can copy over to XB and tweak to test what we need to test until we rely on Workspaces?

re #5
I did a quick search of `core/modules/workspaces/tests` for the work "transaction" and didn't find any results

😬 So … test it is… 🤓 Bumping to and changing to because of this. Thanks for checking!

Tagging , not because individual (content or config) entities could get corrupted, but because from an XB end user POV, it's the combination of all auto-saved things that together should get published, otherwise the live end result will NOT look like what they created (until they fix the entity transactions whose transactions were rolled back).