How to commit the current state after every custom task

As long as you don’t define your custom tasks as asynchronous, engine does not commit the current transaction. The problem is all my custom tasks has to be run in synchronous mode and if the task throws a BPMNError or Exception, it rollbacks the whole process execution and thus I cant see what has gone wrong in the process execution. I know that committing after every task will become an overhead for the system but i can afford that trade-off. How can do this commit after every custom task execution?

Thanks.

Perhaps someone more experienced than me will have a better answer for, but I’ll give it a try:

I know of no way to force a transaction to be committed other than having the process have a wait state. That’s what an async task does, it puts the execution in a wait state and schedules the task to be accomplished whenever it can. I have a feeling that any attempt to induce a wait state by another means will probably break whatever is causing your requirement to have everything execute synchronously. I think that leaves two options:

  1. Change/work around whatever requires the synchronous tasks
  2. Model the error flows using Error Boundary Events, so your process can handle the errors gracefully.

Can you clarify what is causing the need for synchronous execution?

Will

thanks for your reply @wwitt

I am simulating some keyboard and mouse functions of a user. Every task is dependent on the previous task which means a user can not list his orders without submitting the login page so I can not change this sync behaviour to async and unfortunately choice 1 is eliminated in this case.

For the choice 2; I have to define this Error Boundary Events programaticaly that shouldnt bother the business analyst or whoever the designer of the process. For ex: In my case I am killing/deleting the process instance by JAVA API if an Exception or BPMN error is thrown in the middle of process execution. At first I do it by writing my own custom AsyncExceptionHandler but this didnt work for the sync operations and then go more deep into source code and modify execute method of ClassDelegate class(flowable-engine module) and put my deleting process instance logic there but the problem is since the whole process is sync mode, engine rollbacks the whole execution and I cant find any process instance to be deleted because they are all rolebacked from db. I need something which commits every sequence execution immediately to db.

https://docs.camunda.org/manual/7.5/user-guide/process-engine/transactions-in-processes/

Here in Camunda it has some features like asyncBefore=true and asyncAfter=true which pretty solves my problem. If I define my service tasks with asyncBefore=true or asyncAfter=true, I will both guarentee the commit and the synchronous of my custom tasks at the same time. Also it says

Asynchronous Continuations can be configured before and after an activity. Additionally, a process instance itself may be configured to be started asynchronously.

Is there a way to integrate Camunda’s this feature in Flowable doing on my own or it requires many low level changes?

Perhaps there is some confusion as to what making a task async does, since it will not cause tasks to be executed out of order. Marking a task as async puts the process in a wait state and schedules a job to complete the task. When the job is completed, it will then move on the the next task. From what I’ve read I think our async is very much like Camunda’s asyncBefore. I don’t think we have an equivalent to asyncAfter, though if all of your tasks are marked async I don’t think there would be any difference between where the wait points would be placed.

Here is an excellent blog post on async tasks in Flowable

1 Like

Hi @wwitt. I updated all my service tasks as async and now they are creating their own transaction boundaries which was the only desire I have for this issue :slight_smile:

I think Camunda’s before/after async functionality comes into place where you need hetero clusters . I don’t have much knownledge about their architecture but It seems they also wanted to put a functionality like AOP in the execution.

Anyway thanks for your help :slight_smile: