Repository navigation
Consolidate repeated commit tasks and warn when a transaction queues many - #8156
Conversation
TeamCity resultsUpdated 2026-10-11 17:33 PDT for
✅ passed · 🟡 failed, not a blocker · ❌ needs attention · 🕒 not current (ran before the branch's latest commit) Failures
Sample Manager Starter postgres 🕒
|
| // Counts this transaction's monitors rather than the shared throttle, which other threads' commits also hit | ||
| private static int warningsFor(boolean commit, int count, IntConsumer register) | ||
| { | ||
| List<RepeatedCommitTaskMonitor> monitors; |
There was a problem hiding this comment.
Could be a Stream instead
There was a problem hiding this comment.
True. Switched.
| /** The stack through the first frame outside DbScope's commit task plumbing: the code that registered the task */ | ||
| private static String getStackKey(Throwable t) | ||
| { | ||
| StackTraceElement[] frames = t.getStackTrace(); |
There was a problem hiding this comment.
Use SqlExecutingSelector.getStackKey(), which is identical?
There was a problem hiding this comment.
The two differed in their "plumbing frames" list. I consolidated and switched to using Class instead of hard-coded class names.
|
Manual testing looks good. Confirmed with a list configured for entire list indexing. On develop, indexEntireList() was called once per deleted row; on the FB, indexEntireList() was called once per batch of deletes. |
…1225) ## Rationale This PR makes EHR's post-commit demographics work run once per transaction instead of once per row: new-animal recaching, and updates to async demographics providers. It uses the accumulating commit task added in the related platform PR. ## Related Pull Requests - LabKey/platform#8156 ## Changes - Recaching of newly created demographics records is batched per container - Async demographics provider updates are batched per container and provider, covering every id changed in the transaction
…8193) ## Rationale Big transactions spend seconds after commit reloading cache entries they've already invalidated; this replays each transaction's DatabaseCache work as one task and skips what a later removal or clear undoes. A container delete measured 1,194 post-commit reloads taking 2-17 s, nearly all for ontology caches that the same delete clears. Also adds a DEBUG summary of large commit task queues, since the throttled repeated-task warning can't show what fills one. ## Related Pull Requests - #8156 ## Changes - Replay a transaction's cache removals, clears, and reloads after commit from a single commit task, in the order they happened - Skip reloads that a later removal of the same key, or clear of the same cache, would discard - Log the most common task classes and their run times for large commit task queues at DEBUG ## Tasks - [x] Claude Code Review - [x] Manual Testing @labkey-martyp - [x] Delete container with lots of sample types and datasets (perf) - [x] Stale data check across sessions - [x] Transaction rollback doesn't update cache - [x] Batched cache clears (ClearMaterialSourceCacheTask) - [x] Warning for unbatched cache clears (datasets) - [x] Test Automation --------- Co-authored-by: labkey-tchad <tchad@labkey.com>
Rationale
Instead of doing work per row, we're better served by doing it once per transaction. Also, a warning will help us find the call sites adding lots of commit tasks.
Related Pull Requests
Changes
Tasks