Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

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

Links may not function; however, this content may be relevant to outdated versions of the product.

Locking a work object locks its cover too.

Updated on November 15, 2015

Question

Why does Process Commander lock a cover work object when one of its covered work objects is being updated?

Answer

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.

 

Tags

Pega Platform 7.1.1 - 7.4 Case Management Financial Services Healthcare and Life Sciences Insurance Communications and Media Government Healthcare and Life Sciences Consumer Services

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us