Priority: Major - P3
Resolution: Gone away
Affects Version/s: None
Fix Version/s: None
Sprint:Repl 2019-08-12, Repl 2019-08-26, Repl 2019-09-09, Repl 2019-09-23, Repl 2019-10-07, Repl 2019-10-21, Repl 2019-11-04, Repl 2019-11-18, Repl 2019-12-02, Repl 2019-12-16
In one our transaction performance test on mongodb 4.0.9, we saw many write conflict errors and the write conflict error does not indicate which document it is conflicting on.
The environment is only running with one primary mongodb 4.0.9 with no secondary nodes in one machine.
- we tested in mongodb 4.0.10 later and everything passed
- then, we switched to `readConcern: local' in 4.0.9 and everything passed too
- our job mostly just does append operations and does not have any real write conflicts so that seeing many write conflicts is strange to us
We are curious why changing `readConcern` levels can change write conflict behavior. In theory, they should behave the same and it is more about timing. Or, the server should throw a different error.
As the production system will use `readConcern: snapshot`, we are worried whether we might see this issue back in production?
Can we get an explanation what is the relationship between readConcern and write conflict errors?