pessimistic locking

Question

I am considering implementing pessimistic locking in Appian. However, I have heard that pessimistic locking can potentially degrade performance because it restricts concurrency. 
 In practice, how much impact does pessimistic locking typically have on performance? Also, from a best practice perspective in Appian, what kind of design or implementation approaches should be considered? 
 Specifically, I would appreciate guidance on topics such as: 
 
 In which scenarios does pessimistic locking have a significant performance impact? 
 When should pessimistic locking be used, and when should it be avoided? 
 If pessimistic locking is required, are there any design techniques or best practices to minimize its performance impact?

Mike Schmitt · Answer

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.