[SERVER-34577] read_after_optime.js fails on mongoe Created: 19/Apr/18 Updated: 29/Oct/23 Resolved: 14/Sep/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.0.3, 4.1.4 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Henrik Edin | Assignee: | Unassigned |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Backport Requested: |
v4.0
|
||||||||||||
| Sprint: | Platforms 2018-08-13, Platforms 2018-08-27, Platforms 2018-09-10, Platforms 2018-09-24 | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 0 | ||||||||||||
| Description |
|
Reproduce by doing this:
readConcern is not implemented for embedded. What should the correct behavior be for embedded? I see these alternatives:
|
| Comments |
| Comment by Githook User [ 14/Sep/18 ] |
|
Author: {'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}Message: (cherry picked from commit 45fccee20b37579662fabc6268a76a52f00661c4) |
| Comment by Githook User [ 14/Sep/18 ] |
|
Author: {'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}Message: |
| Comment by Githook User [ 14/Sep/18 ] |
|
Author: {'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}Message: (cherry picked from commit 5de2e9361b92fbbc59625636eecbe6bd1f1a78c5) |
| Comment by Githook User [ 14/Sep/18 ] |
|
Author: {'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}Message: |
| Comment by Henrik Edin [ 31/Jul/18 ] |
|
Calling waitForReadConcern / waitForWriteConcern for embedded sounds resonable to me. Do you want to bounce it back to me to give it a try? |
| Comment by Tess Avitabile (Inactive) [ 30/Jul/18 ] |
|
I would recommend that embedded accept the same values for readConcern as standalones. Standalone nodes accept readConcern levels of local, majority, and available. They do not support the readConcern levels snapshot or linearizable, and they do not support the options afterClusterTime, afterOpTime, or atClusterTime. This can be accomplished by calling waitForReadConcern(), similarly to ServiceEntryPointMongod. This will perform the correct validation for non-replica-sets, and it will not do any waiting. Similarly for writeConcern, embedded should accept the same values as standalones. Standalones accept w:"majority", w:1, and w:0. Embedded can get the same behavior by calling waitForWriteConcern(), like in ServiceEntryPointMongod. This will not wait for replication. I'm not sure whether the embedded storage engine is durable, so I'm not sure whether it will wait for durability. Also, I wanted to follow up on the issue I described for transactions. Since this session info is not parsed, the individual reads and writes in the transaction will succeed as if they were not in a transaction (but they will not be atomic). Then when commitTransaction or abortTransaction is run, it will fail because the command was not run within a session. This is strange behavior. Do you have another mechanism for making sure users do not send transactions to the embedded database (for example, the drivers' transactions helpers are disabled)? |