-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 5.0.9, 6.0.0-rc8
-
Component/s: None
-
Fully Compatible
-
ALL
-
v6.1, v6.0, v5.0
-
Sharding EMEA 2022-07-11, Sharding EMEA 2022-07-25, Sharding EMEA 2022-08-08, Sharding EMEA 2022-08-22, Sharding EMEA 2022-09-05
-
20
Consider the following scenario:
- A StaleDatabaseVersion error is thrown due to db version mismatch (no critical section in place)
- The exception is bubbled up and spawn a database refresh
- The database critical section is acquired
- The database refresh completes and installs the new db version in the DSS
- The critical section is released
To guarantee correctness of the critical section we must ensure that all the refreshes started before the critical section acquisition (3.) will be invalidated and no new refreshes could start before (5.)
- causes
-
SERVER-69930 Unexpected error message in the logs attempting to refresh the version of a dropped database
- Closed
- depends on
-
SERVER-69108 SCCL can immediately return config and admin metadata without triggering a refresh
- Closed
- is depended on by
-
SERVER-69444 Make the joining of concurrent critical section and refresh look the same between DSS and CSS
- Closed
- is related to
-
SERVER-70793 Make database metadata refresh first check new metadata under the IS lock before taking X lock
- Closed
- related to
-
SERVER-68661 Deadlock with transactions after step down
- Closed