#3678 closed defect (bug) (fixed)
Counts: prevent lost concurrent metadata deltas
| Reported by: | johnjamesjacoby | Owned by: | johnjamesjacoby |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.6.16 |
| Component: | General - Performance | Version: | |
| Severity: | normal | Keywords: | |
| Cc: |
Description
bbPress originally recalculated counts from content, but moved to stored deltas to keep forum submissions responsive. #1799 introduced the forum, topic, reply, and voice bump functions in r3826 and moved normal topic and reply operations from recount queries to deltas in r6036. r5309 added user contribution deltas for #1694, retaining raw recount fallbacks when metadata was missing. The benchmark in ticket:1799#comment:22 reduced average new-reply time from about 18.54 seconds to 5.39 seconds, with similar improvements for topic creation and moderation actions. Counts were allowed to be temporarily imperfect, with repair tools providing eventual correction. That performance tradeoff should remain the default.
The current bump helpers read the post or user metadata value, apply a difference in PHP, and then write the new value. Concurrent submissions can read the same old value and one write can overwrite the other, silently losing a delta until a repair runs. This is narrower than ordinary temporary count inconsistency.
Investigate atomic delta updates that preserve submission performance without adding full recount queries to the normal posting lifecycle. Preserve existing filters, non-negative clamping, metadata cache invalidation, multisite user-option keys, and public function lifecycles. Include a posting-path performance comparison and cover concurrent or deterministically interleaved updates, missing metadata, supported topic and reply statuses, and aggregate forum counts.
This affects both trunk and the 2.6 maintenance branch.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
In 7453: