pessimistic locking

RE: pessimistic locking

shivakanthreddyp0001 — Tue, 19 May 2026 05:04:11 GMT

Hi MM,

Seems your requirement "the action can be performed by several thousand users at the same time" is against one of the Appian recommendations

Appian recommendation to race condition.

Security settings - reducing the number of people with access, therefore reducing concurrency
Business organization - although a wide audience has access, only a select few are considered "owners" and responsible for data updates.

I would suggest looking for alternate approach for your requirement.

RE: pessimistic locking

Stewart Burchell — Mon, 18 May 2026 11:09:02 GMT

You should find the following a helpful jump-start:

community.appian.com/.../pessimistic-locking

RE: pessimistic locking

Mike Schmitt — Tue, 12 May 2026 12:24:17 GMT

[quote userid="335211" url="~/discussions/f/best-practices/40366/pessimistic-locking/154584"]Appian does not provide a direct equivalent of `SELECT FOR UPDATE`, which means multiple users may end up selecting the same “next” voucher concurrently.[/quote]

If you implement a process that quickly (in successive nodes) does this check-then-write, structured like I described in my prior comment, then users will not be able to do this. Not accidentally, and not even if they're testing to try to break the system you have set up.

[quote userid="335211" url="~/discussions/f/best-practices/40366/pessimistic-locking/154584"]

whether pessimistic locking on such an object could become a bottleneck or cause noticeable performance degradation.

[/quote]

If your system can already handle several thousand users working concurrently, a system like the one I described should make little to no performance difference.

[quote userid="335211" url="~/discussions/f/best-practices/40366/pessimistic-locking/154584"]Any insights would be greatly appreciated[/quote]

Just design something and test it. Keep the lead-up sequence tight, and pay attention to the ordering of the nodes so as to handle the different use cases (e.g. when two users both click the same task within a few seconds of each other from their task lists).

RE: pessimistic locking

MM — Tue, 12 May 2026 11:07:28 GMT

Sorry for the delayed follow-up, and thank you very much for your responses.

Thank you for the detailed explanations so far — they are very helpful.

Let me add more context about my actual use case, as it seems quite relevant to the DB-backed task example you mentioned.

In our business scenario, multiple users work together to review and correct already-registered voucher (transaction) records in Appian.
The workflow is not task-based; instead, users pick records from a shared pool and work on them one by one.

The intended behavior is:
- When a user starts working on a voucher, its status is updated to “In Progress”.
- The voucher that was previously being handled by the user is set back to “Accepted” (or a completed state).
- We need to ensure that the same voucher cannot be picked by multiple users at the same time.

In a traditional database design, this would typically be handled using something like `SELECT FOR UPDATE` to atomically claim the next voucher.
However, as far as I understand, Appian does not provide a direct equivalent of `SELECT FOR UPDATE`, which means multiple users may end up selecting the same “next” voucher concurrently.

Because of this limitation, we are considering introducing a dedicated object (or table) to manage voucher assignment and status, and using pessimistic locking to ensure exclusive ownership while a voucher is being edited.

My concern is scale: in peak periods, several thousand users may perform this operation at roughly the same time.
That raises the question of whether pessimistic locking on such an object could become a bottleneck or cause noticeable performance degradation.

Given this context, I would appreciate guidance on:
- Whether this type of “first-claim-wins” record assignment is a reasonable use case for pessimistic locking in Appian
- Any design patterns or architectural techniques to minimize contention and performance impact (for example, batching, sharding, or alternative locking approaches)
- Or whether there is a more Appian-native pattern that would be preferable for this kind of scenario

Any insights would be greatly appreciated.

RE: pessimistic locking

Mathieu Drouin — Mon, 27 Apr 2026 21:28:32 GMT

This article provides a good roundup of the trade offs as well as a App Market implementation

https://community.appian.com/success/w/article/3213/data-locking-strategies

RE: pessimistic locking

Mike Schmitt — Thu, 23 Apr 2026 13:45:48 GMT

This is entirely context dependent. What are you hoping to implement this on?

For instance, I've implemented this before to do database-backed faux-group-tasks - as in, when a user sees a "task list" that's really queried from a DB where you control who sees the "task names" via whatever databse-backed controls you devise, and clicking the link (instead of actually opening a running task) launches a process that then freshly invokes the actual task. After clicking, a quick DB query establishes that nobody else has opened it yet, and if not, a quick write is made to soft-assign it to that user. If someone else had opened it, the user is routed to a "fallback" task telling them someone has opened it already.

As long as this is well thought out, and conscientiously designed, the "performance impact" is essentially nothing. It works so quickly that users wouldn't notice any difference even under stress testing conditions, IIRC.

But if your use case is something far removed from this (which I have no way of knowing since you didn't really specify), then I can't really speak to it.

RE: pessimistic locking

Stefan Helzle — Thu, 23 Apr 2026 12:12:51 GMT

Well, if you need locking, the impact is a consequence of that decision.

My first question would be more like, why do you think you would need locking.