The Read Preferences spec siad that a thread's first read in a request pins it to a replica-set member, and stays pinned until the request ends or the thread reads with a preference that the pinned member cannot satisfy. THE CHANGE: When a driver pins a thread to a member, it remembers the read preference used for this read – the mode, tags, and secondaryAcceptableLatencyMS. If the next read has a different mode, tags, or secondaryAcceptableLatencyMS, unpin the member and start the member-selection process from scratch.
NOTE: All primary operations within the request must use the same socket, even if interleaved with operations on secondaries. (For simplicity, drivers may also use a single socket on each secondary, but this is not required.)
- depends on
-
RUBY-475 Changing read preference should unpin read pool
- Closed
-
CDRIVER-239 Unpin member when read preference changes
- Closed
-
NODE-74 Unpin member when read preference changes
- Closed
-
SERVER-7636 Do not use cached connection when read preference changes
- Closed
-
CSHARP-838 Unpin member when read preference changes
- Closed
-
JAVA-692 Even when using db.requestStart/requestEnd, unpin member when read preference changes
- Closed
-
PYTHON-431 Unpin member when read preference changes
- Closed