-
Type: Task
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Sharding
-
Sharding 2018-12-03
Currently, killCursors is one of the commands allowed to start a transaction. All requests sent to a shard as part of these commands forward the transaction options of the cross-shard transaction and start single replica set transactions (cluster killCursors can do so if it kills a pinned cluster cursor). Shards aren't allowed to change the read concern of their local transaction once it has been started, so the first request to each shard must include the read concern that will be used for the remainder of the cross-shard transaction, including the atClusterTime read concern option. Unfortunately, this means killCursors must select and pin a global read timestamp for the entire cross-shard transaction, even though it has no real meaning when killing a cursor and the command cannot easily leverage the targeted shards to pick a good timestamp (that avoids no-op writes or reduces the chance write conflicts).
This ticket is to consider preventing killCursors from starting a cross-shard transaction, to avoid the issues above. It would still be allowed as a subsequent statement, so users can kill any cursors established in their current transaction, but they would not be able to start a new transaction that kills an already existing cursor.
As part of this ticket, the ability to select a global read timestamp should be removed from cluster killCursors.
- depends on
-
SERVER-36587 Committing a transaction which was started with a killCursors command can fail
- Closed
-
SERVER-37349 Subsequent statements in a transaction should target shards using the global read timestamp
- Closed
- related to
-
SERVER-43425 Remove TODO listed in SERVER-37045
- Closed