[SERVER-45881] Investigate and implement desired Flow Control throttling for multi-document transactions Created: 30/Jan/20 Updated: 29/Oct/23 Resolved: 13/Mar/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.2.6, 4.4.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Maria van Keulen | Assignee: | Daniel Gottlieb (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Backport Requested: |
v4.4, v4.2
|
||||||||||||
| Sprint: | Execution Team 2020-03-09, Execution Team 2020-03-23 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Multi-document transactions can be subject to Flow Control at prepare or commit time. However, by this point, the work and resources for the transaction have already been consumed, so further subjecting the transaction to Flow Control would prolong an already costly operation. The work for this ticket should be to investigate the appropriate means to avoid throttling prepare/commit/abort for transactions while still preventing new transactions from beginning when there is substantial replication lag. prepare/commit/abort acquires this lock, so the fix for this might be a matter of excluding that opCtx at that particular point from Flow Control. |
| Comments |
| Comment by Githook User [ 26/Mar/20 ] |
|
Author: {'email': 'daniel.gottlieb@mongodb.com', 'name': 'Daniel Gottlieb', 'username': 'dgottlieb'}Message: (cherry picked from commit f13ed6853bb43b07a63bb41f95a462587a7c4a18) |
| Comment by Githook User [ 17/Mar/20 ] |
|
Author: {'email': 'daniel.gottlieb@mongodb.com', 'name': 'Daniel Gottlieb', 'username': 'dgottlieb'}Message: (cherry picked from commit f13ed6853bb43b07a63bb41f95a462587a7c4a18) |
| Comment by Githook User [ 13/Mar/20 ] |
|
Author: {'name': 'Daniel Gottlieb', 'username': 'dgottlieb', 'email': 'daniel.gottlieb@mongodb.com'}Message: |
| Comment by Siyuan Zhou [ 20/Feb/20 ] |
|
Oh. If I understand correctly, flow control only matters on the global lock. That's why you are wondering about the side operation context because a retryable write should have already acquired the global lock so it opts out flow control on the write to transaction table. |
| Comment by Daniel Gottlieb (Inactive) [ 20/Feb/20 ] |
|
siyuan.zhou my understanding is that prepare/commit/aborting a sharded transaction uses a separate operation context for writing oplog entries. This new operation context starts fresh without any locks, and flow control tickets are allocated when first acquiring a global lock. Do retryable writes also use a "side-operation context" for writing to the transaction table, or does that write piggy-back on the existing operation context/storage transaction? |
| Comment by Siyuan Zhou [ 03/Feb/20 ] |
|
Retryable writes have a similar behavior. They create oplog holes and write into the transaction table. Do we want to exclude their writes into transaction table from flow control as well? |