Info

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.

Top User Comments

xgen-internal-githook commented on Thu, 26 Mar 2020 15:31:55 +0000: 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 xgen-internal-githook commented on Tue, 17 Mar 2020 15:36:50 +0000: 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 xgen-internal-githook commented on Fri, 13 Mar 2020 13:56:58 +0000: 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 siyuan.zhou@10gen.com commented on Thu, 20 Feb 2020 22:20:02 +0000: 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. daniel.gottlieb@10gen.com commented on Thu, 20 Feb 2020 20:15:26 +0000: 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? siyuan.zhou@10gen.com commented on Mon, 3 Feb 2020 03:45:56 +0000: 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?

Steps to Reproduce