How about using a work object as a gatekeeper. That is, you lock the work object and then modify the operator record. Since only one of you can lock the work object, locking it acts as a gatekeeper. /Eric
You’d only need one work object total, and you’d not need to even commit (unless you have other data that needs commiting). You could use the obj-open or obj-open-by-handle activity method steps with the “lock” checkbox, and then when you want to release the lock, you can use the page-unlock activity method.
That one work object could be created ahead of time and continually re-used as your gatekeeper. It doesn’t even matter whether it is resolved or not. /Eric
ok the problem here is that when lock is not obtained by requestor, it is trying for some time and then if it is not able to obtain the lock, the step status fails and the execution proceeds to the next step.
So what I am currently doing is a recall of the same activity when the step status fails. But I am not sure how robust is the design.
Is there any possibility to create a custom class for Operators and map it to pr_operators table with locking enabled?
Even if you had a class with locking enabled, you'd still need to solve your problem of how to detect when the lock fails to be obtained. Try using a post-condition on the activity step that checks "StepStatusFail" and branches appropriately if it's true. /Eric
That is the current implementation in place.. And seems to be working fine.
But with this approach, FIFO functionality is failing. As I recall the activity on step status fail to obtain lock, in the mean while if an other requestor comes in and tries to obtain lock, lock is handed over to the new requestor and hence FIFO fails
Right, FIFO is not supplied by the Pega locking facility. It merely gives you the lock if it's available and denies it if someone else has it. It's like a token. One requestor can have it.
Note that even if you were able to make a new class that allowed locking, the same lack of FIFO would prevail there as well.
To implement FIFO, how about having your listener take each service call and queue up an item for an agent. In each item, store info about which operator record to modify, and what field of the operator record should be modified, and what value it should be set to. The order of items in the queue would provide your FIFO, and since the agent would be the only one taking items out of the queue, there would be no locking issue.