>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3616990. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !246 >>> <p>Split out of <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/yoyaku/-/work_items/3616975" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/yoyaku/-/work_items/3616975</a></span>, which opened on the suspicion that the entity cache deletes inside the hold transaction could deadlock two concurrent bookers. A purpose-built two-booker test was written there and did not reproduce that collision, so this change no longer rests on it. What remains is simpler and was never in doubt.</p> <p>A hold takes the slot row with SELECT FOR UPDATE and saves its lines inside that transaction. Every entity saved deletes its own row from cache_entity straight away, from inside the transaction, because EntityStorageBase::doPostSave() calls resetCache() before it invokes the insert hook. Cache TAG invalidation is already deferred past the commit by core's CacheTagsChecksumTrait; the entity cache rows are not.</p> <p>So the slot row lock, which is the one thing a rush contends on, is held across work that does not need it. <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/yoyaku/-/work_items/3615593" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/yoyaku/-/work_items/3615593</a></span> measured that queue: the knee is between 40 and 80 simultaneous bookers, and at 80 there were 48 transactions waiting at once with almost every wait edge on the one slot row. The codebase is already explicit about keeping that section short; the constraint manager resolves attachments outside it for exactly this reason.</p> <h3>Two candidate changes</h3> <p>ONE. Stop caching what is not read back that way. None of the twenty two content entity types sets persistent_cache, so all of them inherit TRUE, which nobody chose. A booking is close to the worst candidate: written on every hold, release, confirm and expiry, and read through queries and aggregates rather than by id, so the cache pays an invalidation per write to serve almost nothing. The seat map already avoids hydrating bookings on the hot path. The transaction is the same case and is saved inside the lock beside its lines. MEASURED, because removing a cache can cost reads: with persistent_cache FALSE on the booking and the transaction, every query budget class still passes unchanged, and those assert exact counts.</p> <p>TWO. Defer the delete past the commit, which is more general because it would protect every entity type rather than the two that opt out. The mechanism is addPostTransactionCallback() on the transaction manager, reached by decorating the cache.entity backend so deleteMultiple() queues while inTransaction(). It carries the hazard core names in the same place: an invalidation that has been delayed must not be readable by another request, which core solves by returning INVALID_CHECKSUM_WHILE_IN_TRANSACTION. A decorator has to answer that too, and getting it wrong serves a stale booking, which is worse than the cost it saves.</p> <h3>What stays out of scope</h3> <p>The read-hot, write-cold types keep their cache: venue, place, grade, section, resource, tariff, slot and configuration are operator-edited and are exactly what a persistent entity cache is for. And a dedicated lock anchor, <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/yoyaku/-/work_items/3616896" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/yoyaku/-/work_items/3616896</a></span>, is a different question: it changes what is locked, not what the transaction then writes.</p> <p>Proposed resolution: take ONE, since it is measured and small, and leave TWO recorded here as the general form should another entity type ever want it.</p> <h3>Where this stands</h3> <p>The premises hold on current 1.x. persistent_cache appears nowhere in the module, so all twenty two content entity types still inherit TRUE; the hold still saves inside the transaction that holds the anchor row locks, HoldEngine opening it, LockAnchors taking them with forUpdate(), and the bookings and the transaction saved before the commit; and addPostTransactionCallback() and INVALID_CHECKSUM_WHILE_IN_TRANSACTION are both still in core, so TWO stays implementable. Two things have moved. The locked section is longer than when this was written, because <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/yoyaku/issues/3620039" title="Status: Closed (fixed)">#3620039: Consolidate a party inside the hold that split it, so a busy house does not lose it</a></span> now consolidates a party inside the hold&rsquo;s own locks. And the queue figures quoted above predate the locking work, <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/yoyaku/issues/3618513" title="Status: Closed (fixed)">#3618513: Anchor locks are taken in the order the plan reaches the rows, so two holds naming overlapping sets deadlock</a></span>, <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/yoyaku/issues/3617101" title="Status: Closed (fixed)">#3617101: Keep what each scope has taken on its lock anchor, so a hold reads a row rather than a sum</a></span> and <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/yoyaku/issues/3618572" title="Status: Closed (fixed)">#3618572: A claim counts the whole hall again whenever it has held a seat</a></span>, so they describe a contention level that no longer exists, which is why the queue is worth re-measuring before either option is taken rather than after.</p> <p>AI-Generated: Yes (Claude Code investigated the transaction, ran the query budget measurement and drafted this summary; I reviewed it before posting.)</p>