flushing activiti data to the database

Is there a way to force activiti to write the internal state to the database? I would like something similar to flushing the session in Hibernate?

The problem I am facing is that I have two flows (say flow A and B). A listener on a task in flow A wants to transition flow B by one or two steps. Say flow B has tasks K-L-M-N. The listener on flow A want to transition Flow B to task N if either L or M are the current task.I do this by doing the fllowing consecutively:1. search tasks on flow B, if taskDefinitionKey matches L -> transition the task2. search tasks on flow B, if taskDefinitionKey matches M -> transition the task

This works fine if flow B is on task K or N, keeping it there.This works fine if flow B is on task M. In that case 1. does nothing and the flow ends up on task NThis fails when flow B is on task L. In that case task L is transitions on 1. moving the flow to task M. However when determining the current task in step 2., it still return that L is the current task.

Is there a way to force the code to "know" that flow B has already transitioned in 2?

I read that async may be a solution to this, but I need everything to execute in one transaction. There are a lot of validations happening in both flows, and success should be all or nothing.

Using signal events is not an option in our case. In most cases these are really user tasks which need to be transitioned.Also (but not relevant to this issue) I am unable to signal event tasks when they are in a subprocess.

Then I don't understand it anymore. You said you need to execute everything in one transaction. But you are user tasks? A user task typically runs in its own transaction. Maybe you can provide a more complete picture what you want to achieve.

We have two flows (say flow A and B).Flow B has several steps, say tasks K - L - M:K: complete dataL: wait for flow A to progress to a certain stateM: allow user to enter more data

Step M in flow B allows the user to do everything which is possible in task K plus something extra.At a certain point in flow A, process B should progress until it is in task M.This is done using an script task (in flow A) which tries to transition flow B. If task K exists, it is completed. Then it checks if task L exists and transitions that as well.

If task K did indeed exists, then the system indicates that K is still the current task which assures that the transitioning of task L fails.

Task L is modelled as a user task. This is done for two reasons: - in some cases, the user can actually do something using this task while waiting (thoug the user is not allowed to complete the task)- It is not a receive task as we had problems signalling tasks when contained in (embedded) processes.

I guess I could model this case using a boundary signal, but that feels wrong. This would mean that I have to model both a normal transition and a boundary signal transition from task L to M which both do exactly the same thing.