Question
ComponentMaker Limited
GB
Last activity: 27 Mar 2018 10:50 EDT
NOT "Read-Only" Node Level Data Pages
I have a read-only node level data page D_XYZ and I have a Page List property in Work- called XYZList. I also have a Table which has this Page List as the source. I have a editable checkbox column in the table bound to .pySelected.
I create a case and I select some rows in my Table and I submit the flow action and my .pySelected values are persisted to my in-memory read-only Node level data page. I create a new case and these values are pre-selected in my new Case's Table.
Should I be able to modify the data in a read-only data page from a Thread level Table?? Or am I missing something?
Pegasystems Inc.
US
To be certain that pySelected values is not being persisted to the database - which is highly doubtful, in the Advanced tab for a Property, beneath "Persistence", you can check the box labeled "Do not save property data".
Do not save property data
Your concern is that you have a Node-level List Data Page (in a cluster there are multiple nodes), the Clipboard page for that Node-level page has been updated by a user to identify selected pages, when a different user launches a new Thread and views that Node-level Data Page, the user sees the Node-level Data Page in its current state.
To prevent this you would need to ensure that pySelected values are NOT posted to the Clipboard until submit. That is, selections only exist in the browser,
ComponentMaker Limited
GB
Thanks Lee,
So the behaviour I'm seeing is that the pySelected values are only updated in the Node Level DP after clicking submit (when posted as you suggested).
Further testing also reveals that any editable control will allow a user to update in memory the data in a Node level page on submit if the Table (for example) is bound to a list that refers to a Node level page.
This means that any thread on any case on that Node will see the updated page in memory - so essentially this page is not Read Only - unless Read-Only is defined as not being persisted.
Niall
Pegasystems Inc.
US
Sounds like there needs to be some kind of "lock" or "mutex" on a Node-level DP.
On submit, the Node-level DP is "locked", pySelected values updated if lockable, as soon as the pySelected values are no longer needed they are returned to their original "false" state, then the Node-level DP is "unlocked".
Of course a Node-level DP itself cannot be locked, but some other persisted, lockable Data instance could be used.
ComponentMaker Limited
GB
This is on the CLSA 7.31 image BTW - so the behaviour may be specific to the patch version I've downloaded. I will try on my patched 7.31 cloud instance.
To be honest I think that there should be greater memory protection for Requestor and Node level pages for in memory updates not initiated via a data page or some other controlled mechanism, mainly to stop unintentional updates by developers who are not aware of the scope of the data page and may change the scope of a page without understanding the full implications of doing so.
A mutex would at least allow concurrent threads to update the Data Page safely if you actually wanted this behaviour, but then this would have to be synchronised across nodes and we all know how painful distributed locking can be.