Why asynchronous continuation?

[roleba...@gmail.com]

Aren't the transaction boundaries in the picture
https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/#why-asynchronous-continuations
the same for synchronous continuations? The first activity is a User Task which commits the transaction by definition (because it is a wait state) https://docs.camunda.org/manual/latest/user-guide/process-engine/img/transactions-1.png from https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/#wait-states

So why is asynchronous continuation needed to make the "Generate invoice" independent to "Provide shipping address"?

[thorben....@camunda.com]

Hi,

the async continuation allows you to complete the user task successfully regardless whether the service task fails or not. For a tasklist user this can make a difference: Without the asynchronous continuation, the user may see an exception that is unrelated to the task completion. I hope that makes sense.

Cheers,
Thorben

[roleba...@gmail.com]

Ok, that makes sense. Are the following assumption about transaction boundaries correct?

In a synchronous behavior the transaction spans over multiple stable states to the next waiting state:
user taks -> on complition begin TX-1 -> execute multiple stable states like synchronous service tasks -> commit TX-1 -> entering the next waiting state.
In case of a rollback the the whole user task would be rolled-back also and the process instance would not be saved to the database at all.

In a asynchronous behavior the transaction ends at the beginning of an asynchronous service task for example:
user taks -> on complition begin TX-1 -> commit TX-1 -> begin TX-2 -> execute asynchronous service task -> commit TX-2 -> entering the next waiting state.
In case of a rollback of TX-2 the service task of TX-1 would still be saved to the database.

[roleba...@gmail.com]

I have a typo in my last sentence. It should be
"In case of a rollback of TX-2 the USER task of TX-1 would still be saved to the database."

[thorben....@camunda.com]

Hi,

I think you understood it correctly. One thing though: Regarding your first example, you wrote

In case of a rollback the the whole user task would be rolled-back also and the process instance would not be saved to the database at all.

This may be a misunderstanding, but the process instance is in the database. It is in the state of when you triggered the first user task though (i.e. all process-instance-state-related effects of the service tasks and the second user task are rolled back).

Cheers,
Thorben

[roleba...@gmail.com]

Great! Thanks for helping me!

I missunderstood something by reading the following sentence:
"In case of Exceptions the state is rolled back to the last persistent wait state of the process instance. It might even mean that the process instance will never be created!" [1]

[1] https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/#reasoning-for-this-design

[thorben....@camunda.com]

You're welcome. That last sentence aims at the case where for example the first task in a process is a synchronous service task that fails. Then starting the process instance fails entirely and no process instance is persisted in the database.

Cheers,
Thorben