[SERVER-48557] Omit cursor.atClusterTime field from read replies in transactions Created: 03/Jun/20 Updated: 29/Oct/23 Resolved: 15/Jun/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.7.0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | A. Jesse Jiryu Davis | Assignee: | Lingzhi Deng |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Repl 2020-06-29 |
| Participants: |
| Description |
|
In
As a consequence of the implementation, cursor replies to snapshot reads that are in transactions also gained "atClusterTime", and we decided that was fine. Let's change our minds and omit the field for replies to commands in transactions. It's not useful. |
| Comments |
| Comment by Githook User [ 15/Jun/20 ] |
|
Author: {'name': 'Lingzhi Deng', 'email': 'lingzhi.deng@mongodb.com', 'username': 'ldennis'}Message: |
| Comment by Lingzhi Deng [ 09/Jun/20 ] |
|
Currently, we append atClusterTime in responses when the readConcern has atClusterTime or the server has picked an atClusterTime for a snapshot read (only when it is not in a transaction). So normally, snapshot reads in a transaction won't have atClusterTime in the responses because the readConcern doesn't have an atClusterTime and snapshot in transactions are speculative. But if a transaction is done via mongos, it would then have an anClusterTime (appendAtClusterTimeToReadConcern). This means that snapshot reads in transactions via mongos would have an atClusterTime in the responses. So in order to keep the same behaviors for transactions (for replica sets and sharded clusters), we should not return atClusterTime in responses for transactions regardless of whether an atClusterTime is specified. |