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.