[SERVER-30960] Find and Modify Many Created: 06/Sep/17 Updated: 15/Nov/21 Resolved: 07/Sep/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Victor Stewart | Assignee: | Mark Agarunov |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Description |
|
Find and Modify Many would go a HUGE way to helping with multi-origin signals that result in unavoidable race conditions. I have a case where users in motion generate rolling location readings, push them to the server and search for users nearby, and then generate events based on changes from the previous state. Problem is, each device/user generates location readings totally independently. Thus, there's the huge problem of race conditions generating duplicate events and state-update writes. The only real solution is to create a pseudo-lock. Currently, best way to do that is... FIRST use an update-many operation which finds all other users (documents) within radius, and then writes the searcher's "name" on the document. then SECOND a find-many operation that gathers and returns all documents with the searcher's "name" on them. ...then carry on with the processing... then remove the searcher's name from all documents. But if there were a find-and-modify-many operation, those first two steps could be taken care of at the same time. As you can imagine, this series of operations will be carried out a zillion times, so the extra inefficiency will really add up. |
| Comments |
| Comment by Mark Agarunov [ 07/Sep/17 ] |
|
Hello victorstewart, Thank you for the detailed report. Looking over the behavior you've described, this appears to be the same behavior requested in SERVER-714 so I have closed this ticket as a duplicate. Please follow SERVER-714 for further updates on this issue. Thanks, |