Update in-memory serverless locks transactionally for tenant migration recipient

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Fixed
    • Priority: Major - P3
    • 7.1.0-rc0
    • 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

      1. Need to acquire lock
      2. 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.

            Assignee:
            Didier Nadeau
            Reporter:
            Didier Nadeau
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: