Handle Concurrency

RE: Handle Concurrency

chandu — Wed, 28 Feb 2018 11:34:35 GMT

I agree with Alok comments, the Version attribute will suffice the requirement and thus avoids the additional logic handling from Appain and DB.

RE: Handle Concurrency

aloks0189 — Tue, 27 Feb 2018 20:37:21 GMT

Hi Vinay

As I mentioned earlier, we do have various approaches to resolve a problem statement, in my case I just want to have one row in db which needs to get update always instead of creating one row for each survey, and then performing count of the row. In such case you have to go for @Version annotation.

Yes, we can have one @Version for each CDT, and that will be more than sufficient to deal with concurrency.

And we cannot deny the fact is, Appian uses JPA internally to interact with the DB.

docs.appian.com/.../Supported_XSD_Elements_and_JPA_Annotations.html

Above link lists out all the annotations of JPA which is supported by Appian. And if you go through the jpa documentation, they have clearly mention that: @Version is specially meant for, Version-Based optimistic concurrency control and that's what this thread is all about i.e. concurrency management.

And when your product is giving you this feature OOTB, then I don't think it makes any sense of dealing with this requirement using manual logic.

RE: Handle Concurrency

Vinay Kumar Rai — Tue, 27 Feb 2018 16:30:27 GMT

HI Alok,

The @Version annotation can be used on only one field per CDT.

and Comparison check may require additional call to DB every time

Concurrency issue can be prevented by good design.

please refer example below,

A company wants to have a survey on like and dislike basis. Where they will have only one row on db which will have few columns including likeCount and dislikeCount and one task for each user has been assigned. Where the organisation is having thousands of employees,

Approach :

- Create a new table for User Likes and Dislikes

- System Create a new row every time when user like or dislike

- please refer the DB structure below

Id	LikeDisLike	UserId/Name
1	1	100012
2	-1	100013

here in the column LikeDisLike, saves the user survey result

1 for Like

-1 for dislike

If you want the Average or Sum you can early use the aggregate function, and Aggregation is work much faster, and it prevent the concurrency.

even banks also use the same structure for transactions

Thanks

RE: Handle Concurrency

aloks0189 — Tue, 27 Feb 2018 12:23:04 GMT

Hi Vinay

You need to have a version comparison check before writing it to DB in order to avoid the process model node breaks.

This is something which we can deal with. And there are various solution approaches for a particular use case.

And the fact is, @Version is meant for handling the concurrency, if in every single case this lead a process to break, then Appian might not have provided the support for this annotation as part of jpa standards.

Let's eloborate this point, When you want to assign a task to a group, that means concurrency is not your target.

Here is an example:

A company wants to have a survey on like and dislike basis. Where they will have only one row on db which will have few columns including likeCount and dislikeCount and one task for each user has been assigned. Where the organisation is having thousands of employees, and every single users like or dislike will update the same row values again and again by increasing its count.

Here in this scenario, assigning the task to a group is not the solution, instead we are trying to bypass the problem.

In fact we should assign one task to each user. Hence here you need to handle the concurrency

RE: Handle Concurrency

melwyna — Tue, 27 Feb 2018 12:01:57 GMT

I guess, we can do above process with a quick task.. As a quick task allows only one task to be active at a time, there is no way that different user can work on simultaneously..

RE: Handle Concurrency

Vinay Kumar Rai — Tue, 27 Feb 2018 10:39:04 GMT

Hi.

Using @Version notation on CDT, the WTDB will throw an error when concurrency detected, to start you need to manually start the WTBD,
The best approach is to assign the task to a group not the particular user, so whenever the task is accepted to any user, the task no longer visible to other users in the group

RE: Handle Concurrency

aloks0189 — Tue, 27 Feb 2018 09:21:14 GMT

Hi ravinderl352 you can use @Version annotation for those fields on which you want to have locking mechanism enabled.

For this you need to download the xsd of the corresponding CDT, define @Version annotation this will make sure to release the lock only when one transaction is completed. And in fact you can capture the update version to keep the track of, how many times this row have been modified.

Hope this will help you

RE: Handle Concurrency

Abhay Giri — Tue, 27 Feb 2018 07:02:01 GMT

HI Ravi,

I think you can achieve this by using MNI(Multiple Node Instance) Property . I am assuming here you are assigning the task to a group of people, So you can use MNI and select as below:

Regards

Abhay