Locking a work object locks its cover too.
Why does Process Commander lock a cover work object when one of its covered work objects is being updated?
Updating a covered work object can result in update of the cover too, thus the lock on the cover.
Updating a covered work object can result in the raising of a ticket that instructs processing to jump form the covered work object to the cover. The cover needs to be locked so that other requestors attempting to update the cover concurrently are denied write access to at the outset of their processing.
The unacceptable alternative would be that such other requestors might begin their processing, carry it out, but then be denied write access at the time of attempted commit operation.
Published May 9, 2005 — Updated November 15, 2015