Understanding the Lock Mechanism in Pega

Now, let's delve into the Pega lock mechanism.

To begin, Pega employs both database-level locks, which are of shorter durations (usually in milliseconds), and Pega-level locks, which extend over more extended periods (determined by user operations, often a few minutes). While you have the option to disable Pega-level locks using the Optimistic locking strategy (discussed later), database-level locks cannot be turned off; they are an integral part of the infrastructure layer. Moving forward, I'll elaborate on Pega-level locks.

1. Fundamentals of Pega-Level Locks

When an individual initiates an assignment, the system transitions the state to "Perform" mode and acquires a lock. This lock data is then added to the "PR_SYS_LOCKS" table in the database, where it is systematically managed. Throughout this phase, no other user can access the same assignment. Upon the user's submission or cancellation of the assignment, the state shifts to "Review" mode, and the lock is released. The corresponding record is subsequently removed from the table.

If an individual attempts to access an assignment already locked by another user, a message will be displayed as follows, and there is no option to unlock it.

If you try to open an assignment that you've locked in another session, a different message will appear, particularly in scenarios where you log into the system using the same ID from a different browser or terminal. In this case, you'll have the option to forcibly log out the other session. It's important to remember that Pega locks are designed to be exclusive to one thread.

Locks can also be released when a user logs out or when the system restarts. If a user leaves assignments open and closes the browser by clicking the Windows close box, the locks continue to be held by the requestor, preventing others from updating the work objects for the next 30 minutes (referred to as a "soft lock") or until the next system restart. It's important to note that a JavaScript event or function cannot detect the closing of the browser window. Therefore, users are encouraged to perform proper logout operations. This rule is applicable even in Single Sign-On (SSO) environments.

2. Soft Lock vs Hard Lock

The lock remains effective for 30 minutes before it expires. Post-expiration, the lock transitions into a "soft lock," allowing another user to take possession. If a different user opens an assignment under a soft lock, no warning is presented, and the user may not be aware of its soft lock status. In the database, the corresponding record in the PR_SYS_LOCKS table is updated by the new user. Locks that occur before expiration are occasionally denoted as "hard locks," contrasting with soft locks.

2-1. Operational Mechanism

Here's how the hard lock / soft lock mechanism operates in the Pessimistic Locking(Default Locking, or Allow one user Locking) strategy:

2-1-1. At 9:00 am, user A accesses an assignment in Perform mode. The system records a new entry in the PR_SYS_LOCKS table. With the default expiration set at 30 minutes, the pxExpireDateTime property is configured for 9:30 am. User A's requestor ID is stored in the pxOwnerId property. Subsequently, user A steps away from their desk, leaving the assignment screen open.

2-1-2. Until 9:30 am, no one can acquire the lock in this scenario.

2-1-3. At 9:31 am, the lock expires. Although the record in the PR_SYS_LOCKS table persists (auto-deletion doesn't occur), user A's lock is no longer a "hard lock." At this point, user B has the opportunity to acquire the lock. Upon user B opening the assignment at 9:31 am, the system updates the pxExpireDateTime and pxOwnerId properties of the existing record. The new expiration time is now configured for 10:01 am.

2-1-4. User A returns to their desk at 9:45 am. If they click the Save or Submit button, an error message will appear on the screen (as depicted in the screenshot below) because the lock on this case has already been relinquished(Lost). This behavior remains consistent, irrespective of user B's status (whether user B still holds the lock or has already submitted).

2-1-4-1. If user A clicks the Save button, the following message is displayed.

2-1-4-2. If user A clicks the Submit button, the following message is displayed.

Q1: Does clicking the Save button by user A, after opening an assignment, extend the expiration time (pxExpireDateTime)?

A: No, the expiration time remains fixed from the start.

Q2: If the lock expires but is not stolen by another user, what happens? For instance, if user A opens an assignment at 9:00 am and clicks the Save button at 9:31 am, will user A encounter an error message due to the expired lock?

A: No, the error message only appears when the lock is either stolen (updated) or released (deleted). If no one steals the lock, the lock record persists in the PR_SYS_LOCKS table, indicating a "soft-lock" state. User A should be able to save or submit without encountering any issues.

2-2. How to Alter the Expiration Period

The default expiration period is set to 30 minutes, but you have the flexibility to modify it. There are two locations where this adjustment can be made.

2-1. If you wish to alter it for each individual case type, make the adjustment in the Case Type rule.

2-2. If you aim to implement the modification system-wide, make the update in the Data-Admin-System (pega) instance.

* If you make updates in both, the Case Type rule will take precedence over the Data-Admin-System instance.

* I recommend opting for the Case Type rule approach because managing multiple environments through the Data-Admin-System approach can be a bit intricate. For instance, exporting and importing the Data-Admin-System instance from Dev to Prod may incorrectly update the production level from 5 to 2, so it's advisable not to do so. Having someone remember to manually update the Data-Admin-System instance for each environment can also be cumbersome. The Case Type, being a rule instance, can be migrated through RAP(Product Rule) without encountering complexities.

3. Pessimistic Locking vs Optimistic Locking

The Pega level object locking, as elaborated earlier, is referred to as "Pessimistic locking," in contrast to "Optimistic locking." Essentially, Pessimistic locking encompasses both Pega level lock and database level lock, while Optimistic locking relies solely on the database level lock (*). The Optimistic locking approach was introduced in Pega 7, and the default setting is Pessimistic locking.

• "Allow one user" means Pessimistic Locking.
• "Allow multiple users" means Optimistic Locking.

* From a technical standpoint, even in Optimistic locking, a lock is momentarily acquired when a user clicks the "Save" or "Submit" button. This duration is in milliseconds and closely aligns with the swiftness of a database-level lock. If the objective is to completely deactivate Pega level locking, the only viable approach is to disable locking from the Class Group (as explained later in #5), although this is not recommended. Typically, concerns about collisions are minimal if updates occur solely from the UI. In scenarios where business requirements involve updates from a background service and collision avoidance is desired, one can implement retry functionality using a Queue Processor.

From the standpoint of data consistency, we personally lean towards Pessimistic locking. If I were an end user, I'd prefer working on my assignment exclusively, free from concerns about the possibility of someone stealing and updating the record in the midst of my work. The downside of Pessimistic locking is that all other users must wait until the first user submits or cancels the assignment

In Optimistic locking, when you click Save or Submit, the system compares the last updated date-time between the one in memory (pyWorkPage) and the one in the database. If they are identical, it indicates that no changes have occurred since you opened the assignment, and no error is triggered. If the one in the database is newer, it signifies that someone has already made updates in the meantime, and the system displays a message . When using an activity to update a work object, ensure that you update pxUpdateDateTime and pxUpdateCounter. These properties are crucial for the system to recognize the update. For instance, if you use the Obj-Save method, it doesn't automatically update these properties. Utilize Process APIs such as Work-.UpdateWorkObject, etc.

This message doesn't specify the exact properties that were updated. If there are numerous properties on the screen, identifying the differences can be cumbersome (and there may be none, as someone might have simply saved it without making changes). The choice of locking strategy depends on the nature of your application, and it's recommended to engage in discussions with business users to determine which approach is more suitable.

4. Lock Mechanism with Case Hierarchy

The lock mechanism is influenced in a specific manner by case hierarchy. please refer Lock Handling in Case Hierarchy

5. Allow Locking Settings at Class Group/Class Level

While we provided instructions on configuring Pessimistic locking or Optimistic locking earlier, there is an additional prerequisite setting at a lower level – either the Class Group or Class form. For Work instances, locking must be enabled at the Class Group form, while for Non-Work (≈Data) instances, locking must be enabled at the Class form.

5-1. Work (Class Group)

When defining a case type, this checkbox is enabled by default, and you can choose to keep it checked. Keeping it checked maintains Pega level lock, and you can disable it by opting for Optimistic locking. Therefore, there is no advantage in unchecking this box.

5-2. Data (Class)

In contrast to Work, Data has a "Locking" tab in the Class form. When defining a data type and configuring local data storage, this checkbox is automatically enabled. When checked, Data instance locking functions similarly to Work, utilizing the PR_SYS_LOCKS table. The distinction between Work and Data lies in the fact that a Data instance is not locked when an assignment is opened but is locked when the data row is being edited (e.g., inline row editing). If unchecked, it operates akin to Optimistic locking.

* If "Allow locking" is enabled for a Data instance, a lock is acquired when someone begins editing the record. An error message is displayed if an attempt is made to update a locked instance, as shown below.

6. Controlling Lock in an Activity

While the system automatically manages object locking when the end user operates on the screen, it requires careful control by the developer when using activities.

In the Obj-Open method or Obj-Open-By-Handle method, there are two checkboxes - "Lock" and "ReleaseOnCommit." Checking "Lock" obtains a lock in this method, while checking "ReleaseOnCommit" releases the lock when the Commit method is executed. When planning to update the instance, it's advisable to check both checkboxes. In most cases, it's a best practice to either check or uncheck both. In exceptional cases, you might want to check only "Lock" and not "ReleaseOnCommit" to retain the lock after Commit (perhaps because additional changes are expected). In such cases, you should manually release the lock later using the Page-Unlock method, etc (*).

Another method, Obj-Refresh-And-Lock, is capable of obtaining a lock. Unlike Obj-Open and Obj-Open-By-Handle, which fetch data from the database every time, Obj-Refresh-And-Lock is employed when you already have a page on the clipboard. If the object is not locked, this method secures a lock and ensures that the version on your clipboard page is either the same as or newer than the version presently in the database. In the case where the object is already locked, this method has no effect.

* While I wouldn't recommend implementing a programmatic solution, if there's a need to manually release a lock, you can do so using either of the approaches below.

Happy Learning :) :)