-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Serverless
-
Fully Compatible
-
Server Serverless 2023-05-29
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
Related to the comment below from a PR :
We only need to install the access blocker only if the state of the document is kStarted. We can have a case where the state document is inserted with kDone (See here)
EDIT: I took a closer look into this onInsert opObserver code for namespace kTenantMigrationRecipientsNamespace. we are doing 2 things
- Need to acquire lock
- Need to install access blocker.
Item#1 is just checking the filed expireAt but not checking the state. I feel the contract should be do 1 & 2 only if the state is kStarted. I like the way donor insert opObserver is written. We should do something similar for more clarity (kStarted does 1 &2; kDone does noting; remaining state should uassert as ErrorCodes::IllegalOperation)
Just a followup comment, I noticed that we might miss releasing the lock in the following situation
Wuow starts
Insert state doc kStarted
Acquire lock via insert opObObserver
// For some reason, Wuow fails.
// Now, we don't release the lock.
Wuow commit(){{}}
I think we need to do register onRollback handler for this write unit of work to release the lock. I am ok addressing in a same or separate ticket.
- related to
-
SERVER-74966 Improve serverless lock/access blocker acquire/release semantics
-
- Closed
-