When an allocation has been created, it is still being created
in the background. The client may request deletion of the
allocation *prior* to the creation of the allocation is entirely
completed. That is fine, but the challenge is we may encounter a
locked row if we're asked to delete while in process.
So, we'll query with with_for_update[0] which should be held until
the lock is released, which is only released when the original
locking transaction closes out[1][2].
Reviewed: https:/ /review. opendev. org/c/openstack /ironic/ +/895039 /opendev. org/openstack/ ironic/ commit/ 58251eb3730e4d4 9322db3e5c7ddc1 69fc9539b0
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/2023.1
commit 58251eb3730e4d4 9322db3e5c7ddc1 69fc9539b0
Author: Julia Kreger <email address hidden>
Date: Thu Jul 27 10:01:31 2023 -0700
DB: Select upon delete for allocations
When an allocation has been created, it is still being created
in the background. The client may request deletion of the
allocation *prior* to the creation of the allocation is entirely
completed. That is fine, but the challenge is we may encounter a
locked row if we're asked to delete while in process.
So, we'll query with with_for_update[0] which should be held until
the lock is released, which is only released when the original
locking transaction closes out[1][2].
[0]: https:/ /docs.sqlalchem y.org/en/ 14/core/ selectable. html#sqlalchemy .sql.expression .GenerativeSele ct.with_ for_update /dev.mysql. com/doc/ refman/ 5.7/en/ select. html /dev.mysql. com/doc/ refman/ 5.7/en/ innodb- locking- reads.html
[1]: https:/
[2]: https:/
Change-Id: I0b68f054c95165 5b01f0cd776feb5 a8c768471ab fed419a838663aa 82973e93e9)
Closes-Bug: #2028866
(cherry picked from commit 6ac0bdab1de8219