[SERVER-44054] support the equivalent of "select for update" Created: 16/Oct/19 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | Mark Callaghan | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | qexec-team | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Query Execution
|
||||
| Participants: | |||||
| Description |
|
The approach suggested here forces the server to do extra work by committing and replicating changes to objects that are otherwise only being read. |
| Comments |
| Comment by Mark Callaghan [ 23/Oct/19 ] | |
|
The case I am concerned about is "select for update" from document A, then modify document B where modifying doc A to get a lock on it is extra work. When the user does "select for update" from doc A, then modifies doc A there isn't extra work using the approach suggested by the blog. | |
| Comment by Carl Champain (Inactive) [ 21/Oct/19 ] | |
|
Hi mdcallag, Thanks for taking the time to submit this request. Kind regards, | |
| Comment by Mark Callaghan [ 17/Oct/19 ] | |
|
Modifying the selected document to prevent it from being modified by others increases the chance for write conflict errors. Since this would be done in a conversational transaction (start, modify "read" doc, modify other doc, commit) then the retry can't be hidden and the app developer must catch/retry. So the benefit for this feature request is performance, efficiency and making life easier for a developer. I asked about this [on mongo-user|https://groups.google.com/forum/#!topic/mongodb-user/IsqqJwaH9sk
|