Avoid concurrent updates from Related action

RE: Avoid concurrent updates from Related action

PhilB — Wed, 04 Jul 2018 10:23:46 GMT

@paragk998 Is correct, but this thread is missing a link to the documentation! :)

RE: Avoid concurrent updates from Related action

Jim Schweitzer — Tue, 03 Jul 2018 14:05:15 GMT

@Version is only really helpful as a failsafe, IMO. It doesn't allow for a good user experience. It will throw an error when trying to save that may or may not be visible to the end user, so it's better to implement some form of locking proactively and build a good UI around it.

RE: Avoid concurrent updates from Related action

paragk998 — Tue, 03 Jul 2018 13:04:15 GMT

Hi Namrata,

you can use @Version (case sensitive) to achieve this.
just need to add @Version in column jpa annotation
eg.
<xsd:element name="id" nillable="true" type="xsd:int">
<xsd:annotation>
<xsd:appinfo source="appian.jpa"> @Id @GeneratedValue @Version </xsd:appinfo>
</xsd:annotation>
</xsd:element>

RE: Avoid concurrent updates from Related action

Pradeep Gudishana — Tue, 03 Jul 2018 12:17:02 GMT

add one integer field in cdt and annotate that field with @version, this field will generate a integer value and this will be auto incremented for every update operation done on that particular row(record)

RE: Avoid concurrent updates from Related action

namratak356 — Tue, 03 Jul 2018 11:53:38 GMT

Pradeep Gudishana Could you please elaborate your answer, How can I achieve lock functoinality using @ version JPA annotation in cdt.

RE: Avoid concurrent updates from Related action

Pradeep Gudishana — Tue, 03 Jul 2018 04:48:42 GMT

Hi Namrata,

Instead, use @version attribute in your cdt which will hold auto lock and raises exception when some others try to modify the same record

RE: Avoid concurrent updates from Related action

Shanmukha — Mon, 02 Jul 2018 09:35:36 GMT

Hi Namrata,

We can also do it in the following way for safe retrieval. Along with flag we can also have who has locked the data. For instance if user A has already locked and he did not attend the task for a week then user B wants to update same data during that week it may create a problem. So for this we can have user name who have locked it then User B will notify User A that he wants to update the record so please release the lock. If the user A is not responding for some time then we can have another Related Action called Release the Lock. This new related action can only be shown when the user A has locked it for respected amount of time. I know it's big work around but this may help user to take any action based on the critical situations.

RE: Avoid concurrent updates from Related action

abishekk109 — Mon, 02 Jul 2018 06:54:29 GMT

Hi,

Use a flag as suggested below in your database to ensure that whether the action is accepted by any other user in the specific group. That way you can ensure the above discussion.

Thanks,
Abishek

RE: Avoid concurrent updates from Related action

Jim Schweitzer — Fri, 29 Jun 2018 17:57:20 GMT

You can also accomplish something similar to what Mike is suggesting by using process analytics. If you have your related actions start a process instead of using a start form, you can use queryprocessananalytics to see if there are any active processes with whatever metadata you track for your record. This may or may not perform better depending on the rest of the structure of your app, but can help avoid database calls to write the locks.

RE: Avoid concurrent updates from Related action

Mike Schmitt — Fri, 29 Jun 2018 17:18:40 GMT

The one technique I've seen used successfully is to include a database column, i.e. "isLocked" (boolean), which gets set to TRUE as soon as a user initiates a particular related action, and the same gets set back to FALSE when the related action is concluded or timed out. And if any user attempts to start the related action while the "locked" value is true, they're diverted away, perhaps to a task telling them that this record is locked.