Preventing Scheduled Process Models from kicking off multiple instances after system downtime?

Jason Ruvinsky

Certified Senior Developer

over 8 years ago

Does anyone have any recommended approaches to preventing a process model that runs on a recurring schedule from kicking off multiple instances after the system is down when it was scheduled to run? We have some processes that run nightly, but can create race-conditions if multiple instances try to run simultaneously.

Thinking about maybe putting in an "Advanced Options" Expression to force it to actually be the scheduled start time (or at least close), and just bypassing running until the next scheduled time that Appian is actually up on the server. Would that do the trick?

Discussion posts and replies are publicly visible

Parents

0 Mike Schmitt
Certified Lead Developer
over 8 years ago

In my case I'm just using the Query DB node, using a command sequence I was able to find which basically locks the record for update. It's been a while, but I remember testing this by intentionally launching parallel instances simultaneously and it still worked as needed - ymmv. I'll transcribe the basic "setup screen" sql statements (with line numbers) here:

1 -- START TRANSACTION
2 -- SELECT COLUMN_TO_UPDATE FROM TABLE_NAME WHERE ID = ac!selectedId FOR UPDATE
3 -- UPDATE TABLE_NAME SET COLUMN_TO_UPDATE = COLUMN_TO_UPDATE + 1 WHERE ID = ac!selectedId
4 -- COMMIT

This allows us to grab the current value of COLUMN_TO_UPDATE and pass that value back into the process via the data outputs, while also incrementing it by one. I assume similar could be done for other data types / operations, such as flipping a boolean flag, following this example.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 Mike Schmitt
Certified Lead Developer
over 8 years ago

In my case I'm just using the Query DB node, using a command sequence I was able to find which basically locks the record for update. It's been a while, but I remember testing this by intentionally launching parallel instances simultaneously and it still worked as needed - ymmv. I'll transcribe the basic "setup screen" sql statements (with line numbers) here:

1 -- START TRANSACTION
2 -- SELECT COLUMN_TO_UPDATE FROM TABLE_NAME WHERE ID = ac!selectedId FOR UPDATE
3 -- UPDATE TABLE_NAME SET COLUMN_TO_UPDATE = COLUMN_TO_UPDATE + 1 WHERE ID = ac!selectedId
4 -- COMMIT

This allows us to grab the current value of COLUMN_TO_UPDATE and pass that value back into the process via the data outputs, while also incrementing it by one. I assume similar could be done for other data types / operations, such as flipping a boolean flag, following this example.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

No Data