Update Data step failing on concurrent updates | Community
Skip to main content
Level 3
Jul 26, 2017 7:48 AM UTC
Solved

Update Data step failing on concurrent updates

Hi,

We have a AC6 6.1.1 with build number : 8594. It has an UPDATe STEP that is trying to insert-or-update into a AC6's own database ( no FDA being used here for this update data step).

This step is in a campaign workflow that has two instance that are trying to update the same row in the same table. But it is throwing an error.

Is there a way, we can enable either a WAIT+QUEUE or a concurrency check to wait in the step till the database lock is available. Is this a configuration ?

/Regards

Kanwal

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Adhiyan
AdhiyanAccepted solution
Employee
Jul 12, 2018 7:41 AM UTC

Hi Kanwaljit,

The solution here could be to use a concurrency check for the workflow instance by using an instance variable called isRunning.

Instance variables are shared by all the parallel executions of the workflows.

Here is a simple test workflow:

The scheduler is triggering an event every minute. The next test activity is going to test the isRunning instance variable to decide

whether or not to continue the execution:

Note: isRunning is the variable name I've chosen for this example. This is not a built-in variable.

Then the activity immediately following the test in the yes branch must set the instance variable in its Initialization script:

instance.vars.isRunning = true

Finally the very last activity in the yes branch must revert the variable to false in its Initialization script:

instance.vars.isRunning = false

Regards,

Adhiyan

6 replies

lukkyluke
Level 2
Sep 20, 2018 7:40 AM UTC

Solved by setting the isRunning-variable to false in the advanced tab in the scheduler-activity. This is code is only triggered upon restart/start and not by "execute pending tasks now"

Translate
lukkyluke
Level 2
Aug 29, 2018 11:24 AM UTC

Hello,

I have implemented your suggested solution into one workflow. However I get problems as soon as the workflow gets paused due to an error. In such scenarios the isRunning variable is still set to true even after restart. Is there any way to auto-reset the instance variables in a workflow when the restart-button is clicked?

Translate
Amit_Kumar
Level 10
Jul 17, 2018 12:15 PM UTC

Hi Kanwaljit,

In Adobe campaign there is no configuration available to enforce locks, you can use SQL activity to use SQL code to use locking if required.

Now you have two option, either change the workflow design to prevent this from happening or you can use below approach, which will cover some use cases with obvious performance tradeoffs.

1. Reduce batch size i.e to 100

2. Use Update records systematically

this should be able to fix your issue but redesigning the workflow should be the ideal solution.

Translate
Adhiyan
Employee
Jul 12, 2018 7:43 AM UTC

Test workflow :

Set up the instance variable:

Translate
Adhiyan
AdhiyanAccepted solution
Employee
Jul 12, 2018 7:41 AM UTC

Hi Kanwaljit,

The solution here could be to use a concurrency check for the workflow instance by using an instance variable called isRunning.

Instance variables are shared by all the parallel executions of the workflows.

Here is a simple test workflow:

The scheduler is triggering an event every minute. The next test activity is going to test the isRunning instance variable to decide

whether or not to continue the execution:

Note: isRunning is the variable name I've chosen for this example. This is not a built-in variable.

Then the activity immediately following the test in the yes branch must set the instance variable in its Initialization script:

instance.vars.isRunning = true

Finally the very last activity in the yes branch must revert the variable to false in its Initialization script:

instance.vars.isRunning = false

Regards,

Adhiyan

Translate
Employee
Jul 10, 2018 12:17 PM UTC

Hi Kanwal,

This functionality is not available currently OOB.

Adobe recommends to improve the design of workflows so that multiple workflows do not try to improve the same schema at the same time.

Thanks,

Deepika

Translate