[SERVER-27786] Implement computeOperationTimeForRead Created: 23/Jan/17 Updated: 05/Apr/17 Resolved: 23/Mar/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.5.5 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Misha Tyulenev | Assignee: | Jack Mulrow |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Sharding 2017-03-06, Sharding 2017-03-27 |
| Participants: |
| Description |
|
Currently the opeartionTime computed in Command::run() is a pessimization that returns the current clusterTime as an operationTime and that may make the following client's requests with readAfterClusterTime set to this value wait when it should not to. for the write operation:
read with readConcern level majority: operationTime is the committed LogicalTime_LOG.
read with readConcern level local: operationTime is the local LogicalTime_LOG.
The last question is how to differ "read" vs "write" operation: |
| Comments |
| Comment by Githook User [ 23/Mar/17 ] |
|
Author: {u'username': u'jsmulrow', u'name': u'Jack Mulrow', u'email': u'jack.mulrow@mongodb.com'}Message: |
| Comment by Randolph Tan [ 16/Mar/17 ] |
|
looks good to me as well |
| Comment by Spencer Brody (Inactive) [ 16/Mar/17 ] |
|
Plan outlined above lgtm |
| Comment by Misha Tyulenev [ 16/Mar/17 ] |
|
spencer renctan Please confirm that you can review the CR once its ready and please ack the proposed solution. |