How can we implement locking in appian? How many types of locking are supported?

Hello Arpit, by locking are you referring here by restricting a user to perform update on existing data if that particular record is already open by some other user?

If you are, as Ravi is asking, looking for some means of preventing concurrent updates to a database row (where the last User's changes get applied, potentially overwriting someone else's changes) then you have the following options:

• Optimistic Locking
  • by using the @version JPA annotation in the CDT you're using to write changes to the database entity. It's not a great option as it simply throws an exception that is caught by Appian and doesn't provision a meaningful user experience
• Pessimistic Locking
  • you can prevent other Users from running concurrent instances of a Process Model. You could write a Process Report and use the results from that to control a Related Action's visibility so that only one person can run an update Process at any time.
  • you can write your own locking solution, by having a separate table that you can write the entity type and entity key of the entity you're wanting to update, and having all Processes that want to update that entity type check this table first to see if there's a lock in place. All updates would then need to explicitly take a lock (before updating the entity) and then delete the lock (after the entity was updated)

 I'm sure others will have other suggestions.

I've also seen adding another boolean column to a database table that determines whether that row is locked or not. So suppose you have a Support Case that is stored in the database. When you start a process to edit, the isLocked parameter would be set to true. Once the user submits the form, the isLocked paramter is set back to false.

The tricky thing with implementing locking is determining what to do if the form gets abandoned. In the example above, suppose I started to edit the form and then forgot about it for days - should the data for that row still be locked? You usually have to couple your locking strategy with a timeout strategy too. For example, I might have an exception timer on the task that makes it expire after 30 min. Then, I can update the database to remove the lock.

The super short answer is that there's no "Lock Process" function or "Lock DB Row" smart service in Appian that's pre-built for you.

Your best bet is to roll your own locking mechanism, which has the distinct advantage of being whatever you want:

Think of what records you'd want to be locked.

Think of what users could be doing to those records that would require them to be locked for that operation.

Think of how you would determine when that operation began and ended (When does it get locked?  When does it get unlocked?) 

Who or what would you tell that this record has been locked?  How would you store the locked / not locked info?  Would you include timestamp and ID of the user who locked it? (You probably should)

Think of what users could and could not do to a record while it's locked by someone else.

Think of how the process would discover whether it's locked or not before they try doing something prohibited by the lock.

Think of what the system should display to the user when they can't do something because the record is locked. (Who locked it, when, and why it's locked?)

Think about what circumstances you would allow the user to break a lock.  How would they do that?

Think about what to do when a record stays locked by an abandoned process.  Does it eventually unlock?  Does it still require someone to break the lock?

Lastly, think about what to do when the whole thing breaks, because yeah it's a lot.  Lets just face that something this complex will almost necessarily have bugs.  How do you handle incidents involving the locking mechanism?  Do you give admins a tool to circumvent broken locking?

I'm a fan of building my own pessimistic locking mechanism by utilizing process model display and a process report. At the start of the process, put in a sub process that checks if their is the same process (such as edit record) of the same record id currently active. If there is an active process, the flow is terminated within the sub process and a helpful interface explaining it is currently locked. If there is no active process, the flow continues as normal.

Here's a link to the playbook on data locking community.appian.com/.../data-locking-strategies