Multi user locking on editable data pages
Hi All,
We have been using editable data pages for different usecases. Editable data pages have locking mechanism which allows us to update the changes on the thread scope. But now, we want to implement this scenario for a portal dashboard.
Any user can go and update from the list. Does editable data pages with optimistic locking works in this scenario? Its not working as expected. Why does Pega doesn't give an option for editable data pages to be node scoped for optimistic locking with auto refresh strategy? Any limitation? How does the locking mechanism works with editable data pages?
Regards,
Nizam
***Edited by Moderator: Pallavi to update platform capability tags***
Pegasystems Inc.
AU
The philosophy of Locking is to control who applies changes to an item that can be saved. Data Pages - even Savable Data Pages - don't have a Locking option; the Locking configuration is determined by Classes that are Concrete. Furthermore, Pessimistic and Optimistic Locking options are only available to Case Types.
Can you clarify what you intend by locking Editable Data Pages? Without knowing the approach to save the changes, locking configuration doesn't come into it.
If what you are after is an approach for User A to make a change to the Dashboard and this become available to other users of the Dashboard, a Savable Data Page of Dashboard Preferences could be loaded, modified and saved by the user making the changes. The next time a user logs in to load the same Dashboard Preferences, they will see the updates.
If users who are currently logged in need a real-time notification that the preferences have been updated, you would need to explore Channel Notifications. Review Configuring a web gadget notification and Adding a custom notification channel ... and the notification channel articles that surround them.
The philosophy of Locking is to control who applies changes to an item that can be saved. Data Pages - even Savable Data Pages - don't have a Locking option; the Locking configuration is determined by Classes that are Concrete. Furthermore, Pessimistic and Optimistic Locking options are only available to Case Types.
Can you clarify what you intend by locking Editable Data Pages? Without knowing the approach to save the changes, locking configuration doesn't come into it.
If what you are after is an approach for User A to make a change to the Dashboard and this become available to other users of the Dashboard, a Savable Data Page of Dashboard Preferences could be loaded, modified and saved by the user making the changes. The next time a user logs in to load the same Dashboard Preferences, they will see the updates.
If users who are currently logged in need a real-time notification that the preferences have been updated, you would need to explore Channel Notifications. Review Configuring a web gadget notification and Adding a custom notification channel ... and the notification channel articles that surround them.
Challenge how genuine the business need is for this to be real-time. A distinct read-only data page referenced by the Dashboard that retrieves the Dashboard Preferences with a "Reload if older than" config of 10 minutes may be sufficiently real-time without needing a new channel infrastructure.
Tech Mahindra
IN
Thanks for the clarification. There are few open questions related to my scenario.
Q1)User changes that happens on the screen will be persist to the database table. If that's the case, can we replace editable data pages to savable data pages always?
Q2) If Q1 is yes, then when should we use editable data pages over savable data pages?
Q3) If the case has optimistic locking, does pega acquires the lock in the savable data page(source list belongs to case types) before saving it in the savable data page? OR Do we need to check the lock again?
Thanks in advance.
Regards,
Nizam