This content has been archived and is no longer being maintained.

Table of Contents


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

Have a question? Get answers now.

Visit the Pega Support Community to ask questions, engage in discussions, and help others.