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

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.

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.