@Version-style optimistic locking for synced Record Types

I’m not sure about the @Version functionality on records.

As a work around, I’ve setup process models to query a process report that checks if another user (User A) is updating the record.  If so, the user (User B) that wants to make an update is displayed a screen with a message stating User A is making an update.

It’s not 100% full proof, but worked for our use cases.

Many ways to do this but one relatively simple way to do it is to store an last update date on the record and retrieve the database record on submission and compare the last update date to the one your retrieved locally in the interface when the user began the work. If the date on the database is later, you show a message to the user and tell them to refresh the info on their screen before resubmitting.

That approach makes sense, but I think there is still a small race condition risk between the time we query the database record and the time we actually perform the update.

For example, we could retrieve the record, confirm that the last updated date still matches, and then another process or user could update the same record before our write happens. In that case, our update could still overwrite the newer change.

Ideally, the version or last updated value should be part of the actual update condition so the validation and write happen atomically. We could do that with a stored procedure, but that would require more implementation effort.

Another option would be to use Appian's optimistic locking behavior with a!writeToDataStoreEntity(), but that is only available from the interface layer, so it would not help in scenarios where the write happens later in a process model.

Because of that, if we need this protection at the process/database level, a stored procedure with a conditional update would probably be the safer approach.

Based on my experience, I always try to avoid using stored procedures unless they are really necessary. They can make the system more difficult to manage and maintain, and in some cases may impact performance. There is also a risk of database vendor lock-in, which can make it more difficult to migrate to a different database system in the future.