[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:
Backports
Related
is related to SERVER-45880 Flow Control lag detection mechanism ... Closed
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: SERVER-45881: Bypass flow control on txn metadata operations.

(cherry picked from commit f13ed6853bb43b07a63bb41f95a462587a7c4a18)
Branch: v4.2
https://github.com/mongodb/mongo/commit/980bb8fdfcb7bb057e6a467d241ce80a99675130

Comment by Githook User [ 17/Mar/20 ]

Author:

{'email': 'daniel.gottlieb@mongodb.com', 'name': 'Daniel Gottlieb', 'username': 'dgottlieb'}

Message: SERVER-45881: Bypass flow control on txn metadata operations.

(cherry picked from commit f13ed6853bb43b07a63bb41f95a462587a7c4a18)
Branch: v4.4
https://github.com/mongodb/mongo/commit/db380ba8f4ff05f9bbdd79f087203b9a6ea2b8ff

Comment by Githook User [ 13/Mar/20 ]

Author:

{'name': 'Daniel Gottlieb', 'username': 'dgottlieb', 'email': 'daniel.gottlieb@mongodb.com'}

Message: SERVER-45881: Bypass flow control on txn metadata operations.
Branch: master
https://github.com/mongodb/mongo/commit/f13ed6853bb43b07a63bb41f95a462587a7c4a18

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?

Generated at Thu Feb 08 05:09:56 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.