>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3616896. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !249 >>> <p>A booker who names no seat asks the house to choose one, and choosing reads what is free. That read happened above the hold's locks, so every booker reaching at once read the same free house and was offered the same seats: the first was served and the rest refused for a seat that was free when they asked. On a house of 8000 sold at one price, 160 bookers at once sold 1460 seats and were refused 84 per cent of what they asked for.</p> <p>The same read was also too big. A hold read the whole session to answer questions about a handful of seats: the pass primer read every free seat of the session twice per hold, the seating read the hall to find a run, and the rule against leaving a place on its own read the hall to judge one row. So the last click of a sale was the dearest one.</p> <h3>What changes</h3> <p>A request reaches the engine as a request rather than as lines, and where its units go is decided inside the locks, against what is committed, so being offered a seat and taking it are one moment. A hold reads the seats it names, by key, and the area it is being seated into: a session's seats are rows of their own carrying whether each has gone, so what is left in an area is a seek rather than a subtraction over a house, and it shrinks as the sale goes on instead of growing.</p> <p>The seating asks for areas a page at a time in house order and turns another page whenever the party would not be sitting together, keeping what it has read, so stopping early can only skip reads it did not need. A party given a part of the house that turns out not to seat it is not refused there: the guess is dropped and the hall asked again with the house open to it. How many of the best areas a party may be given is a field rule on the resource, <code class="language-php">party_area</code>: one keeps every party in the best area and queues them all for it, a number spreads them over that many, and zero spreads over every area with room for them. Four is shipped, and a hall of one area has nothing to decide.</p> <p>What may be locked and what may be read are the same question asked once, so a party can only be seated inside what was locked for it. A party too big for any one area waits on every area it could be seated in; a booker adding to a basket waits on the area their party is already sitting in; and the session is waited on only where the hall offers no areas at all. The locks are taken before anything is written, so a hold no longer holds a site-wide row for the length of its own queue.</p> <p>A seat cannot be sold twice, whoever writes the booking. Claiming moves only rows that are still free, and a hold that moves fewer rows than it claimed is taken back whole rather than committed on top of somebody else's seats. A booking saved outside the hold path is refused rather than written onto a seat another booking holds. Under both, the booking carries the seat it consumes with a unique key over it, so the rule holds even where those rows have drifted from what the bookings say: a session drawn before this module was installed carries none at all, and every guard above reads them. The column is empty whenever a line consumes nothing or names no seat, and repeated empties do not collide, so released lines, pooled units and halls without seats are outside the rule rather than fighting over it. A hold that meets the key is refused the way a full house refuses.</p> <p>What a claim reads is the block it is about, and no longer the house. Every area card carries how many seats its part of the house has left, which was answered by listing every free seat of the session and counting them, and again by a second reader when the hold chose where to seat the party. It is one reading now, counted by the database, narrowed to the parts of the house a tariff is sold in, and kept for as long as an availability figure may be believed: the seats this request has taken since come off it before it is answered with, so a booker sees their own claim at once and everybody else sees it when it is counted again. How many seats a hall holds, and where its grades sit, are facts about the building and are kept between requests, ending when an operator edits it.</p> <p>An area a booker takes by the number is bounded the same way, on what the hall holds there less what the session still offers of it, rather than by summing the bookings inside the lock. Only a pooled area still counts them, having no seats to count instead. That path is how a house of five thousand seats and upwards is most likely to be run, and it was twice the cost of selling seat by seat.</p> <p>The shipped availability lifetime goes from thirty seconds to five. At a hundred and fifty seats a second a thirty second old picture is thousands of seats out of date, and a booker shown one picks seats that have gone.</p> <h3>Measured</h3> <p>A house of 8000 seats in 16 areas, 160 bookers at once, driven from empty:</p> <ul> <li>a party that names no seat: <strong>8000 of 8000 sold</strong>, on 8000 distinct places, where the same run sold 1460 and refused 84 per cent</li> <li>refused while the house still had room: <strong>none</strong>, and asking again rather than refusing made the sale a fifth faster</li> <li>a booker clicking seats: unchanged, 160.2 and 166.6 seats a second before against 164.1 after, run as A, B, A on one machine</li> <li>what a hold costs: the same statements as 1.x, with one read fewer</li> </ul> <p>On a hall ten times the size, 80000 places in 80 areas, forty bookers at once: 16.5 seats a second when the claim endpoint merged, and about 60 now, with a claim's median from 3731 ms to 90 ms. A single claim off an empty house costs 88 ms against 410 ms on 1.x, and reads 51411 rows where it read 213671. A hall whose areas are all assigned, which is how a house this size is likely to be sold, keeps pace with one sold seat by seat: 59.8 seats a second against 59.9, where 1.x managed 3.7.</p> <h3>Filed from this work</h3> <ul> <li><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>, keeping on each anchor how much of its scope is consumed: batched so a party moves each row once it still costs a statement per hold, and nothing reads the number yet</li> <li><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/yoyaku/issues/3617494" title="Status: Closed (fixed)">#3617494: Let the database refuse a second booking on a seat</a></span>, where the presave now refuses a second booking on a seat and the key on the bookings themselves is what is left</li> <li><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/yoyaku/issues/3617848" title="Status: Closed (fixed)">#3617848: Claim a party's places through an endpoint of its own, so the booking page stays cacheable and its notices stay long enough to be read</a></span>, claiming through an endpoint of its own so the booking page stays cacheable</li> <li><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/yoyaku/issues/3617880" title="Status: Closed (fixed)">#3617880: A booker who asks to move to another part of the house is refused for a seat chosen before the wait</a></span>, composing a rearrangement under the locks</li> <li><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/yoyaku/issues/3617891" title="Status: Closed (fixed)">#3617891: Seat a party that cannot sit together in as few pieces as possible, across areas if need be</a></span>, seating a party that cannot sit together in as few groups as possible</li> <li><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/yoyaku/issues/3617528" title="Status: Closed (fixed)">#3617528: Repair a slot whose seats have gone missing, when it is saved</a></span>, repairing a slot whose seats have gone missing</li> </ul> <p>AI-Generated: Yes (Claude Code was used to draft this issue summary and to write the code, the tests and the measurements on the merge request. I reviewed them before posting.)</p>