-
Type: Spec Change
-
Resolution: Fixed
-
Priority: Major - P3
-
None
-
Component/s: Load Balancer
-
None
-
Not Needed
Summary
In the specification for driver support for running MongoDB behind an L4 load-balancer, we specify connection-pinning rules for distributed transactions to ensure all transaction commands target the same service behind the load balancer. Specifically, we say:
"When executing a transaction in load balancing mode, drivers MUST follow the rules outlined in Sharded Transactions with one exception: drivers MUST use the same connection for all commands in the transaction "
I would like to clarify in the spec whether or not this implies that:
"drivers MUST NOT use the same connection for two concurrent transactions run under different sessions from the same client"
In other words, I wonder if the following situation possible:
(1) Client A begins txn with LSID x and TxnNumber 1; the driver pins connection C to serve this txn
(2) Client A sends some pieces of txn (x, 1) but doesn’t commit or abort it yet
(3) Client A begins txn with LSID y and txnNumber 1 on connection C, and sends some pieces of it
(4) Client A commits txn (x, 1)
(5) Client A commits txn (y, 1)
I believe the answer is "this is not possible", which means we could add to the spec a clarification that a pinned connection for a transaction will only run commands for that single transaction until it either commits or aborts.
- is related to
-
SERVER-58504 Abort transactions for a connection when a load balanced connection on mongos is closed
- Closed
- related to
-
RUBY-2868 Pin connections instead of serviceIds for load balanced transactions
- Closed