[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:
Depends
depends on SERVER-56788 Extend the in-memory collection criti... Closed
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 SERVER-56788 will be completed.



 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?

Generated at Thu Feb 08 05:40:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.