[SERVER-44389] Investigate whether the 'preCondition' can be removed from 'applyOps' Created: 04/Nov/19 Updated: 06/Dec/22 Resolved: 07/Nov/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Gregory Wlodarek | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Participants: | |||||||||
| Description |
|
To simplify the removal of the global exclusive lock in applyOps, we should look into today's use cases of the 'preCondition' and if it would be possible to remove it. The 'preCondition' accepts a list of preConditions across multiple databases and collections. This would require us to potentially hold multiple database and collection locks throughout the applyOps command to ensure that the preCondition holds throughout the entire operation. |
| Comments |
| Comment by Kaloian Manassiev [ 04/Nov/19 ] |
|
Just FYI, sharding still has a dependency on the pre-condition for applyOps for the moveChunk, splitChunk and mergeChunk commands. |