Moving a pair of games in one batch failed, because the two games in the batch redeclared the same variables.
The rename that wasn’t one
The group batch renames variables per game. That rename carried a stray backspace character where a word boundary should have been, so two games in one batch redeclared the same variables. This was the finishing hotfix of the season-move work. Multi-game moves no longer fail.
Locks and the partner-link lookup
The partner-link lookup now reads without locks and updates by primary key instead of running a scanning UPDATE.
Row locks for all the games in a batch are now taken up front, in one global order, relabelled games included. Opposite-direction requests queue instead of deadlocking.
Index scripts, left unapplied
The hotfix also carries optional index scripts for lgoppgid, with measured build times. They are not applied.
A pair in one batch failed because of a stray backspace character. Requests moving games in opposite directions now take their row locks in the same global order, so they queue instead of deadlocking.
AI Skills
Use this lesson with the AI assistant you already use
A batch move of two games failed because a variable rename left a stray backspace character, so both games redeclared the same variables. The finishing hotfix also changed how row locks are taken for batches.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: Take Every Row Lock Up Front In One Global Order So Opposite Direction Requests Queue Instead Of Deadlocking
SOURCE: dxdev.com/blog/slug-batch-row-locks-global-order
WHAT HAPPENED: The group batch renames variables per game, and that rename carried a stray backspace character where a word boundary should have been. Two games in one batch therefore redeclared the same variables and the multi game move failed. The hotfix repaired the rename so multi game moves work again. It also changed the locking. The partner link lookup now reads without locks and updates by primary key instead of running a scanning UPDATE. Row locks for every game in a batch, relabelled games included, are now taken up front in one global order. The hotfix also ships optional index scripts with measured build times, but they were left unapplied.
THE RULE: When concurrent requests touch overlapping sets of rows, acquire all the locks before doing the work and acquire them in one agreed global order. Requests that go in opposite directions will then queue behind each other instead of deadlocking.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Every batch operation acquires the row locks for all rows it will touch before it starts modifying anything.
2. The lock acquisition order is a single global order, such as sorted by key, and does not depend on the direction or order of the request.
3. Rows that are relabelled or renamed as part of the batch are included in the up front lock set, and lookups that only read do so without taking locks.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
