[SERVER-17371] findAndModify can update a document that doesn't match the predicate if there are concurrent updates Created: 25/Feb/15 Updated: 26/Feb/15 Resolved: 26/Feb/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 3.0.0-rc9 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Angelo Prado | Assignee: | David Storch |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Steps To Reproduce: |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
After a coupe of days lost troubleshooting a race condition on our end, we determined MongoDB r3.0.0-rc6/rc9 has issues with concurrent findAndModify writes. Specifically we have business logic that acquires a lease (think: lock) on a given object for a few minutes, for processing. The find and modify sets the lease datetime in the present and the query makes sure it's at least three minutes in the past. We found MongoDB 3.0 acquires the same object and modifies it twice, within a matter of milliseconds, having a TOCTOU (time-of-check time-of-use) condition. We are able to reproduce consistently on a threaded environment with several queries going out at the same time. We initially suspected the following issue was the culptrit, but it doesn't seem like it was fixed 100%:
Unfortunately we still see findAndModify returning objects that were modified by a previous findAndModify statement and no longer fullfil the query predicate due to a concurrent update. |
| Comments |
| Comment by David Storch [ 26/Feb/15 ] |
|
Thanks for your help aprado@salesforce.com. Given that neither you nor I can reproduce this issue on the latest release candidate, I am going to close this issue as Cannot Reproduce. If you see similar symptoms again, feel free to re-open. |
| Comment by Angelo Prado [ 26/Feb/15 ] |
|
David, I was able to reproduce on rc9 last week, that's why I thought it was not related to Oddly, after deploying rc10 today... the script does no longer hit the race condition. I cannot longer reproduce with the latest build. |
| Comment by David Storch [ 25/Feb/15 ] |
|
We are having some trouble reproducing this with the provided script. We reproduced immediately on rc6 and rc7, but not rc8, rc9, or rc10. The evidence on our end now suggests that the issue was fixed for rc8 under Could you provide a bit more information in order to help us track this down?
Best, |
| Comment by David Storch [ 25/Feb/15 ] |
|
Thanks aprado@salesforce.com. We have identified an MMAPv1-only issue that is likely to be the root cause. |
| Comment by Angelo Prado [ 25/Feb/15 ] |
|
MMAP
|
| Comment by David Storch [ 25/Feb/15 ] |
|
Thanks for reporting this issue. Could you tell me which storage engine your server is configured with? That is, are you seeing this problem against the default MMAP v1 storage engine or against WiredTiger? Best, |