[SERVER-56888] Require a unique identifier in critical section reasons Created: 12/May/21 Updated: 11/Oct/21 Resolved: 05/Jul/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Pierlauro Sciarelli | Assignee: | Pierlauro Sciarelli |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Sharding EMEA 2021-07-12 | ||||||||
| Participants: | |||||||||
| Description |
|
When acquiring a collection critical section, a "weak" reason is currently provided for DDL operations. For example, the reason on rename participants simply includes the involved collections. The objective of this ticket is to make the critical section reason more strict, requiring the inclusion in the reason of a unique identifier (e.g. the collection uuid) to avoid re-joining in case of bugs around similar operations. This ticket is to address the problem both for recoverable and in-memory critical section, once |
| Comments |
| Comment by Pierlauro Sciarelli [ 05/Jul/21 ] |
|
Closing because it has been decided to not proceed since all DDL coordinators have a fixed LSID and that by itself is a unique identifier "protecting" the critical section acquisition/releasing at an upper level. |
| Comment by Pierlauro Sciarelli [ 12/May/21 ] |
|
LSID + txnNumber sounds good to me! |
| Comment by Kaloian Manassiev [ 12/May/21 ] |
|
FYI, the critical section is per collection and the UUID is constant for the lifetime of the collection, so perhaps not the collection UUID However, since we will be assigning unique LSIDs for each coordinator, we can just use the LSID + txnNumber pair perhaps? |