Different transaction in single-thread execution?

I’m using quite often the mechanism of asyncBefore and asyncAfter: they allow to configure “pointcut”, so when an execution reaches them, control is returned to the client thread and a background job thread is set to continue with the execution.

This mechanism implies a transaction to commit before this point and a new transaction to start when de job thread continues the execution.

What would be really useful to our application is to define some “pointcut” where the transactions were commited and new transaction started but without returning control to the client thread until next waiting task is reached (userTask/timerEvent/receiveTask/etc…).

Is this possible in camunda?

This should happen when all transactions commit correctly. If a transaction issues a rollback, then the execution could be put in a state where an async continuation deals with it from the point the last transition correctly commited.

Consider the following model snippet:

Task1 and Task2 have the same assignee.

When Task1 is completed, our system offers Task2 to the user so he can complete it.

This can be done because Task2 is active when thread control is returned after Task1 completion and Automatic 1 and 2 have executed without exception.

We would like to set asyncAfter=true in automatic1 in order to avoid Automatic1 task to be retried when it have been succesful bu Automatic2 failed.

When we set asyncAfter=true, control is returned to the thread just after Automatic1 so Task2 is not yet available and cannot be offered to the user.


This thread may be of interest. In particular, consider the link to the pattern described as the UI Mediator.



Thanks for the link.

We solved the problem pointed in the link by asking for new tasks every time the user completes a task and redirecting to the new task in the processInstance in case it is assigned to him (similar to UI Mediator).

This solution cannot be applied in case the executions have async continuations, as the new tasks are not available when completion of the task1 is finished (as the continuation is async, and the control has been already returned when task2 is created).

Waiting after every task completion for some amount of time to see if a new task arises is not a solution at all for us (application may seem to be stalled/not responsive).

So what we are really interested in is to know whether camunda can handle with different transactions in the same thread (not async).

In case it is not possible, I’d suggesto to include this in further versions.

The solution we are thinking about (in case what I am asking for is not possible in camunda) is to show a processInstance view as soon as the control returns and check in the background periodically if new tasks are available. This would fit our needs, but would be indeed more optimal solution to have the control returned when a new waiting state is reached (no async execution to force new transactions).

@mabertran are you only going forward in your tasks? You do not have any “Go Back” functionality, or various branching and merging?

I do not know in advance what would follow the point where I would like a transaction to be commited and a new transaction to be started. This is part of the problem as I don’t know what the system may look for after an async continuation (user task, external event to happen, finish of other concurrent tasks, …).

Take the model I included in the message as an example of a simple case.