pessimistic logic

RE: pessimistic logic

Stewart Burchell — Tue, 28 Nov 2023 08:43:01 GMT

There is a solution for this in the AppMarket: community.appian.com/.../pessimistic-locking

RE: pessimistic logic

yashig2399 — Tue, 28 Nov 2023 07:55:33 GMT

I need to implement pessimistic locking in my process model. can you share what is implemented for locking?

RE: pessimistic logic

Stewart Burchell — Thu, 16 Dec 2021 08:51:20 GMT

This is how I originally implemented pessimistic locking and for the most part this works...except...there is a small window of opportunity where two users can run the same related action because they hit it at the same time and the data hasn't yet been replicated/stored where the process report accesses it. In short: it's not a fool-proof method.

One of my colleagues has written a utility that closes this gap and delivers a robust pessimistic locking solution.

RE: pessimistic logic

mounikak0002 — Thu, 16 Dec 2021 07:51:54 GMT

yes, I want to protect related actions for multiple executions??

RE: pessimistic logic

Stefan Helzle — Thu, 16 Dec 2021 07:29:33 GMT

Appian is pretty good in keeping track of process activity. Using a process report, you can easily detect any other active instances. Display that to the user and disable the submit button.

Then you do not need to implement any locking in DB which has its drawbacks as check-lock and set-lock is not a single atomic transaction. Two processes checking at the same time will collide.

RE: pessimistic logic

davel001150 — Wed, 15 Dec 2021 20:34:22 GMT

Yes! This makes me realize exactly how to phrase what I intend to phrase. Thank you, Stefan.

Every single implementation of pessimistic locking has to be unique to the particulars of the thing you're trying to pessimistically lock, and both what and who you're trying to lock it from. They all have to be different based on your specific goals.

My solution: A. Is protected by a Non Disclosure Agreement B. Is too highly technical for me to go into absolutely all the particulars here if I could C. Even if I could remember all of them precisely D. Would therefore be more difficult than making your own even if I could tell you every detail, and finally E. Wouldn't even work for your situation if you could copy it exactly.

RE: pessimistic logic

Stefan Helzle — Wed, 15 Dec 2021 18:27:05 GMT

What do you want to achieve? Protecting a record from multiple executions of related actions?

RE: pessimistic logic

priyankabandi — Wed, 15 Dec 2021 17:29:36 GMT

Can you please share what you have implemented for locking?

RE: pessimistic logic

ramakg — Wed, 29 Apr 2020 06:22:08 GMT

Thank you for advice

RE: pessimistic logic

davel001150 — Tue, 28 Apr 2020 20:06:29 GMT

You add a boolean or equivalent "locked" column to the database table that stores your record, or that is linked in some way to your record. You can also include a timestamp and user identification, but those aren't strictly required for it to work.

When a user attempts to start an action that could edit the record, you first query the lock. If it's set to true, you inform the user that you're so sorry they're not allowed to use it now. If it is set to false, you let the user continue their action, and the very first thing you do is set the locked column to true.

The very last thing your process does after all work on whatever action is complete is to set the lock back to false.

On the surface it's very easy. The difficult part is robustly handling all the various different forms of edge cases, such as abandoned processes not permanently locking all users out of a particular record, and other extraneous bits you have to account for when making your solution. But a rudimentary system to get you going isn't much beyond what I described above.