pessimistic locking

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.

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.

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 

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.

You should find the following a helpful jump-start:

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