From 5702ca0ddd0513c9b9e8b19fa17332b55e086a97 Mon Sep 17 00:00:00 2001 From: Tim Stawowski Date: Tue, 19 Nov 2024 13:29:12 +0100 Subject: [PATCH 1/2] fix(assets): display bpmn-element images --- .../understanding-transaction-handling-c7.md | 16 ++++++++-------- .../understanding-transaction-handling-c7.md | 16 ++++++++-------- .../understanding-transaction-handling-c7.md | 16 ++++++++-------- .../understanding-transaction-handling-c7.md | 16 ++++++++-------- .../understanding-transaction-handling-c7.md | 16 ++++++++-------- .../understanding-transaction-handling-c7.md | 16 ++++++++-------- 6 files changed, 48 insertions(+), 48 deletions(-) diff --git a/docs/components/best-practices/development/understanding-transaction-handling-c7.md b/docs/components/best-practices/development/understanding-transaction-handling-c7.md index a22bccca41..9e46442b06 100644 --- a/docs/components/best-practices/development/understanding-transaction-handling-c7.md +++ b/docs/components/best-practices/development/understanding-transaction-handling-c7.md @@ -92,27 +92,27 @@ Aside a general strategy to mark service tasks as being save points you will oft - _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. -- Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. +- Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. -- Service tasks (or other steps) executing _expensive Ccmputations_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a computationally expensive step does not have to be repeated just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. +- Service tasks (or other steps) executing _expensive Ccmputations_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a computationally expensive step does not have to be repeated just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. -- Receive tasks (or other steps) catching _external events_, possibly with payload Receive Task Message Intermediate Event Signal Intermediate Event : This savepoint makes sure that a external event like a message is persisted as soon as possible. It cannot get lost just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. This applies also to External Service Tasks. +- Receive tasks (or other steps) catching _external events_, possibly with payload Receive Task Message Intermediate Event Signal Intermediate Event : This savepoint makes sure that a external event like a message is persisted as soon as possible. It cannot get lost just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. This applies also to External Service Tasks. **Do** configure a savepoint **before** -- _Start events_ None Start Event Message Start Event Signal Start Event Timer Start Event: This savepoint allows to immediately return a process instance object to the user thread creating it - well before anything happens in the process instance. +- _Start events_ None Start Event Message Start Event Signal Start Event Timer Start Event: This savepoint allows to immediately return a process instance object to the user thread creating it - well before anything happens in the process instance. -- Service tasks (or other steps) invoking _remote systems_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that you always transactionally separate the potentially more often failing remote calls from anything that happens before such a step. If a service call fails you will observe the process instance waiting in the corresponding service task in cockpit. +- Service tasks (or other steps) invoking _remote systems_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that you always transactionally separate the potentially more often failing remote calls from anything that happens before such a step. If a service call fails you will observe the process instance waiting in the corresponding service task in cockpit. -- _Parallel joins_ Parallel Join Inclusive Join Multiinstance Task: Parallel joins synchronize separate process pathes, which is why one of two path executions arriving at a parallel join at the same time will be rolled back with an optimistic locking exception and must be retryed later on. Therefore such a savepoint makes sure that the path synchronisation will be taken care of by Camunda's internal job executor. Note that for multi instance activities, there exists a dedicated "multi instance asynchronous after" flag which saves every single instance of those multiple instances directly after their execution, hence still "before" their technical synchronization. +- _Parallel joins_ Parallel Join Inclusive Join Multiinstance Task: Parallel joins synchronize separate process pathes, which is why one of two path executions arriving at a parallel join at the same time will be rolled back with an optimistic locking exception and must be retryed later on. Therefore such a savepoint makes sure that the path synchronisation will be taken care of by Camunda's internal job executor. Note that for multi instance activities, there exists a dedicated "multi instance asynchronous after" flag which saves every single instance of those multiple instances directly after their execution, hence still "before" their technical synchronization. The Camunda JobExecutor works (by default) with [exclusive jobs](https://docs.camunda.org/manual/latest/user-guide/process-engine/the-job-executor/#exclusive-jobs), meaning that just one exclusive job per process instance may be executed at once. Hence, job executor threads will by default not cause optimistic locking exceptions at parallel joins "just by themselves", but other threads using the Camunda API might cause them - either for themselves or also for the job executor. **Don't** configure save points **before** -- User tasks and other _wait states_ User Task ScrReceiveipt Task Message Intermediate Event Signal Intermediate Event Timer Intermediate Event Event Based Gateway including steps configured as _external tasks_ Service Task Script Task Send Task Message Intermediate Event Message End Event: Such savepoints just introduce overhead as [wait-states](https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/#wait-states) on itself finish the transaction and wait for external intervention anyway. +- User tasks and other _wait states_ User Task ScrReceiveipt Task Message Intermediate Event Signal Intermediate Event Timer Intermediate Event Event Based Gateway including steps configured as _external tasks_ Service Task Script Task Send Task Message Intermediate Event Message End Event: Such savepoints just introduce overhead as [wait-states](https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/#wait-states) on itself finish the transaction and wait for external intervention anyway. -- _All forking_ and _exclusively joining gateways_ Exclusive Gateway Parallel Join Inclusive Join: There should just be no need to do that, unless execution listeners are configured at such points, which could fail and might need to be transactionally separated from other parts of the execution. +- _All forking_ and _exclusively joining gateways_ Exclusive Gateway Parallel Join Inclusive Join: There should just be no need to do that, unless execution listeners are configured at such points, which could fail and might need to be transactionally separated from other parts of the execution. ### Adding save points automatically to every model diff --git a/versioned_docs/version-8.2/components/best-practices/development/understanding-transaction-handling-c7.md b/versioned_docs/version-8.2/components/best-practices/development/understanding-transaction-handling-c7.md index b05d462ebf..391499be37 100644 --- a/versioned_docs/version-8.2/components/best-practices/development/understanding-transaction-handling-c7.md +++ b/versioned_docs/version-8.2/components/best-practices/development/understanding-transaction-handling-c7.md @@ -92,27 +92,27 @@ Aside a general strategy to mark service tasks as being save points you will oft - _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. -- Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. +- Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. -- Service tasks (or other steps) executing _expensive Ccmputations_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a computationally expensive step does not have to be repeated just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. +- Service tasks (or other steps) executing _expensive Ccmputations_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a computationally expensive step does not have to be repeated just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. -- Receive tasks (or other steps) catching _external events_, possibly with payload Receive Task Message Intermediate Event Signal Intermediate Event : This savepoint makes sure that a external event like a message is persisted as soon as possible. It cannot get lost just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. This applies also to External Service Tasks. +- Receive tasks (or other steps) catching _external events_, possibly with payload Receive Task Message Intermediate Event Signal Intermediate Event : This savepoint makes sure that a external event like a message is persisted as soon as possible. It cannot get lost just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. This applies also to External Service Tasks. **Do** configure a savepoint **before** -- _Start events_ None Start Event Message Start Event Signal Start Event Timer Start Event: This savepoint allows to immediately return a process instance object to the user thread creating it - well before anything happens in the process instance. +- _Start events_ None Start Event Message Start Event Signal Start Event Timer Start Event: This savepoint allows to immediately return a process instance object to the user thread creating it - well before anything happens in the process instance. -- Service tasks (or other steps) invoking _remote systems_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that you always transactionally separate the potentially more often failing remote calls from anything that happens before such a step. If a service call fails you will see the process instance waiting in the corresponding service task in cockpit. +- Service tasks (or other steps) invoking _remote systems_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that you always transactionally separate the potentially more often failing remote calls from anything that happens before such a step. If a service call fails you will see the process instance waiting in the corresponding service task in cockpit. -- _Parallel joins_ Parallel Join Inclusive Join Multiinstance Task: Parallel joins synchronize separate process pathes, which is why one of two path executions arriving at a parallel join at the same time will be rolled back with an optimistic locking exception and must be retryed later on. Therefore such a savepoint makes sure that the path synchronisation will be taken care of by Camunda's internal job executor. Note that for multi instance activities, there exists a dedicated "multi instance asynchronous after" flag which saves every single instance of those multiple instances directly after their execution, hence still "before" their technical synchronization. +- _Parallel joins_ Parallel Join Inclusive Join Multiinstance Task: Parallel joins synchronize separate process pathes, which is why one of two path executions arriving at a parallel join at the same time will be rolled back with an optimistic locking exception and must be retryed later on. Therefore such a savepoint makes sure that the path synchronisation will be taken care of by Camunda's internal job executor. Note that for multi instance activities, there exists a dedicated "multi instance asynchronous after" flag which saves every single instance of those multiple instances directly after their execution, hence still "before" their technical synchronization. The Camunda JobExecutor works (by default) with [exclusive jobs](https://docs.camunda.org/manual/latest/user-guide/process-engine/the-job-executor/#exclusive-jobs), meaning that just one exclusive job per process instance may be executed at once. Hence, job executor threads will by default not cause optimistic locking exceptions at parallel joins "just by themselves", but other threads using the Camunda API might cause them - either for themselves or also for the job executor. **Don't** configure save points **before** -- User tasks and other _wait states_ User Task ScrReceiveipt Task Message Intermediate Event Signal Intermediate Event Timer Intermediate Event Event Based Gateway including steps configured as _external tasks_ Service Task Script Task Send Task Message Intermediate Event Message End Event: Such savepoints just introduce overhead as [wait-states](https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/#wait-states) on itself finish the transaction and wait for external intervention anyway. +- User tasks and other _wait states_ User Task ScrReceiveipt Task Message Intermediate Event Signal Intermediate Event Timer Intermediate Event Event Based Gateway including steps configured as _external tasks_ Service Task Script Task Send Task Message Intermediate Event Message End Event: Such savepoints just introduce overhead as [wait-states](https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/#wait-states) on itself finish the transaction and wait for external intervention anyway. -- _All forking_ and _exclusively joining gateways_ Exclusive Gateway Parallel Join Inclusive Join: There should just be no need to do that, unless execution listeners are configured at such points, which could fail and might need to be transactionally separated from other parts of the execution. +- _All forking_ and _exclusively joining gateways_ Exclusive Gateway Parallel Join Inclusive Join: There should just be no need to do that, unless execution listeners are configured at such points, which could fail and might need to be transactionally separated from other parts of the execution. ### Adding save points automatically to every model diff --git a/versioned_docs/version-8.3/components/best-practices/development/understanding-transaction-handling-c7.md b/versioned_docs/version-8.3/components/best-practices/development/understanding-transaction-handling-c7.md index 3a39004b8b..03015d612d 100644 --- a/versioned_docs/version-8.3/components/best-practices/development/understanding-transaction-handling-c7.md +++ b/versioned_docs/version-8.3/components/best-practices/development/understanding-transaction-handling-c7.md @@ -92,27 +92,27 @@ Aside a general strategy to mark service tasks as being save points you will oft - _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. -- Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. +- Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. -- Service tasks (or other steps) executing _expensive Ccmputations_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a computationally expensive step does not have to be repeated just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. +- Service tasks (or other steps) executing _expensive Ccmputations_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a computationally expensive step does not have to be repeated just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. -- Receive tasks (or other steps) catching _external events_, possibly with payload Receive Task Message Intermediate Event Signal Intermediate Event : This savepoint makes sure that a external event like a message is persisted as soon as possible. It cannot get lost just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. This applies also to External Service Tasks. +- Receive tasks (or other steps) catching _external events_, possibly with payload Receive Task Message Intermediate Event Signal Intermediate Event : This savepoint makes sure that a external event like a message is persisted as soon as possible. It cannot get lost just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. This applies also to External Service Tasks. **Do** configure a savepoint **before** -- _Start events_ None Start Event Message Start Event Signal Start Event Timer Start Event: This savepoint allows to immediately return a process instance object to the user thread creating it - well before anything happens in the process instance. +- _Start events_ None Start Event Message Start Event Signal Start Event Timer Start Event: This savepoint allows to immediately return a process instance object to the user thread creating it - well before anything happens in the process instance. -- Service tasks (or other steps) invoking _remote systems_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that you always transactionally separate the potentially more often failing remote calls from anything that happens before such a step. If a service call fails you will observe the process instance waiting in the corresponding service task in cockpit. +- Service tasks (or other steps) invoking _remote systems_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that you always transactionally separate the potentially more often failing remote calls from anything that happens before such a step. If a service call fails you will observe the process instance waiting in the corresponding service task in cockpit. -- _Parallel joins_ Parallel Join Inclusive Join Multiinstance Task: Parallel joins synchronize separate process pathes, which is why one of two path executions arriving at a parallel join at the same time will be rolled back with an optimistic locking exception and must be retryed later on. Therefore such a savepoint makes sure that the path synchronisation will be taken care of by Camunda's internal job executor. Note that for multi instance activities, there exists a dedicated "multi instance asynchronous after" flag which saves every single instance of those multiple instances directly after their execution, hence still "before" their technical synchronization. +- _Parallel joins_ Parallel Join Inclusive Join Multiinstance Task: Parallel joins synchronize separate process pathes, which is why one of two path executions arriving at a parallel join at the same time will be rolled back with an optimistic locking exception and must be retryed later on. Therefore such a savepoint makes sure that the path synchronisation will be taken care of by Camunda's internal job executor. Note that for multi instance activities, there exists a dedicated "multi instance asynchronous after" flag which saves every single instance of those multiple instances directly after their execution, hence still "before" their technical synchronization. The Camunda JobExecutor works (by default) with [exclusive jobs](https://docs.camunda.org/manual/latest/user-guide/process-engine/the-job-executor/#exclusive-jobs), meaning that just one exclusive job per process instance may be executed at once. Hence, job executor threads will by default not cause optimistic locking exceptions at parallel joins "just by themselves", but other threads using the Camunda API might cause them - either for themselves or also for the job executor. **Don't** configure save points **before** -- User tasks and other _wait states_ User Task ScrReceiveipt Task Message Intermediate Event Signal Intermediate Event Timer Intermediate Event Event Based Gateway including steps configured as _external tasks_ Service Task Script Task Send Task Message Intermediate Event Message End Event: Such savepoints just introduce overhead as [wait-states](https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/#wait-states) on itself finish the transaction and wait for external intervention anyway. +- User tasks and other _wait states_ User Task ScrReceiveipt Task Message Intermediate Event Signal Intermediate Event Timer Intermediate Event Event Based Gateway including steps configured as _external tasks_ Service Task Script Task Send Task Message Intermediate Event Message End Event: Such savepoints just introduce overhead as [wait-states](https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/#wait-states) on itself finish the transaction and wait for external intervention anyway. -- _All forking_ and _exclusively joining gateways_ Exclusive Gateway Parallel Join Inclusive Join: There should just be no need to do that, unless execution listeners are configured at such points, which could fail and might need to be transactionally separated from other parts of the execution. +- _All forking_ and _exclusively joining gateways_ Exclusive Gateway Parallel Join Inclusive Join: There should just be no need to do that, unless execution listeners are configured at such points, which could fail and might need to be transactionally separated from other parts of the execution. ### Adding save points automatically to every model diff --git a/versioned_docs/version-8.4/components/best-practices/development/understanding-transaction-handling-c7.md b/versioned_docs/version-8.4/components/best-practices/development/understanding-transaction-handling-c7.md index d2465ecc39..4277c0e8cb 100644 --- a/versioned_docs/version-8.4/components/best-practices/development/understanding-transaction-handling-c7.md +++ b/versioned_docs/version-8.4/components/best-practices/development/understanding-transaction-handling-c7.md @@ -92,27 +92,27 @@ Aside a general strategy to mark service tasks as being save points you will oft - _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. -- Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. +- Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. -- Service tasks (or other steps) executing _expensive Ccmputations_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a computationally expensive step does not have to be repeated just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. +- Service tasks (or other steps) executing _expensive Ccmputations_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a computationally expensive step does not have to be repeated just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. -- Receive tasks (or other steps) catching _external events_, possibly with payload Receive Task Message Intermediate Event Signal Intermediate Event : This savepoint makes sure that a external event like a message is persisted as soon as possible. It cannot get lost just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. This applies also to External Service Tasks. +- Receive tasks (or other steps) catching _external events_, possibly with payload Receive Task Message Intermediate Event Signal Intermediate Event : This savepoint makes sure that a external event like a message is persisted as soon as possible. It cannot get lost just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. This applies also to External Service Tasks. **Do** configure a savepoint **before** -- _Start events_ None Start Event Message Start Event Signal Start Event Timer Start Event: This savepoint allows to immediately return a process instance object to the user thread creating it - well before anything happens in the process instance. +- _Start events_ None Start Event Message Start Event Signal Start Event Timer Start Event: This savepoint allows to immediately return a process instance object to the user thread creating it - well before anything happens in the process instance. -- Service tasks (or other steps) invoking _remote systems_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that you always transactionally separate the potentially more often failing remote calls from anything that happens before such a step. If a service call fails you will observe the process instance waiting in the corresponding service task in cockpit. +- Service tasks (or other steps) invoking _remote systems_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that you always transactionally separate the potentially more often failing remote calls from anything that happens before such a step. If a service call fails you will observe the process instance waiting in the corresponding service task in cockpit. -- _Parallel joins_ Parallel Join Inclusive Join Multiinstance Task: Parallel joins synchronize separate process pathes, which is why one of two path executions arriving at a parallel join at the same time will be rolled back with an optimistic locking exception and must be retryed later on. Therefore such a savepoint makes sure that the path synchronisation will be taken care of by Camunda's internal job executor. Note that for multi instance activities, there exists a dedicated "multi instance asynchronous after" flag which saves every single instance of those multiple instances directly after their execution, hence still "before" their technical synchronization. +- _Parallel joins_ Parallel Join Inclusive Join Multiinstance Task: Parallel joins synchronize separate process pathes, which is why one of two path executions arriving at a parallel join at the same time will be rolled back with an optimistic locking exception and must be retryed later on. Therefore such a savepoint makes sure that the path synchronisation will be taken care of by Camunda's internal job executor. Note that for multi instance activities, there exists a dedicated "multi instance asynchronous after" flag which saves every single instance of those multiple instances directly after their execution, hence still "before" their technical synchronization. The Camunda JobExecutor works (by default) with [exclusive jobs](https://docs.camunda.org/manual/latest/user-guide/process-engine/the-job-executor/#exclusive-jobs), meaning that just one exclusive job per process instance may be executed at once. Hence, job executor threads will by default not cause optimistic locking exceptions at parallel joins "just by themselves", but other threads using the Camunda API might cause them - either for themselves or also for the job executor. **Don't** configure save points **before** -- User tasks and other _wait states_ User Task ScrReceiveipt Task Message Intermediate Event Signal Intermediate Event Timer Intermediate Event Event Based Gateway including steps configured as _external tasks_ Service Task Script Task Send Task Message Intermediate Event Message End Event: Such savepoints just introduce overhead as [wait-states](https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/#wait-states) on itself finish the transaction and wait for external intervention anyway. +- User tasks and other _wait states_ User Task ScrReceiveipt Task Message Intermediate Event Signal Intermediate Event Timer Intermediate Event Event Based Gateway including steps configured as _external tasks_ Service Task Script Task Send Task Message Intermediate Event Message End Event: Such savepoints just introduce overhead as [wait-states](https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/#wait-states) on itself finish the transaction and wait for external intervention anyway. -- _All forking_ and _exclusively joining gateways_ Exclusive Gateway Parallel Join Inclusive Join: There should just be no need to do that, unless execution listeners are configured at such points, which could fail and might need to be transactionally separated from other parts of the execution. +- _All forking_ and _exclusively joining gateways_ Exclusive Gateway Parallel Join Inclusive Join: There should just be no need to do that, unless execution listeners are configured at such points, which could fail and might need to be transactionally separated from other parts of the execution. ### Adding save points automatically to every model diff --git a/versioned_docs/version-8.5/components/best-practices/development/understanding-transaction-handling-c7.md b/versioned_docs/version-8.5/components/best-practices/development/understanding-transaction-handling-c7.md index d2465ecc39..4277c0e8cb 100644 --- a/versioned_docs/version-8.5/components/best-practices/development/understanding-transaction-handling-c7.md +++ b/versioned_docs/version-8.5/components/best-practices/development/understanding-transaction-handling-c7.md @@ -92,27 +92,27 @@ Aside a general strategy to mark service tasks as being save points you will oft - _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. -- Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. +- Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. -- Service tasks (or other steps) executing _expensive Ccmputations_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a computationally expensive step does not have to be repeated just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. +- Service tasks (or other steps) executing _expensive Ccmputations_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a computationally expensive step does not have to be repeated just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. -- Receive tasks (or other steps) catching _external events_, possibly with payload Receive Task Message Intermediate Event Signal Intermediate Event : This savepoint makes sure that a external event like a message is persisted as soon as possible. It cannot get lost just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. This applies also to External Service Tasks. +- Receive tasks (or other steps) catching _external events_, possibly with payload Receive Task Message Intermediate Event Signal Intermediate Event : This savepoint makes sure that a external event like a message is persisted as soon as possible. It cannot get lost just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. This applies also to External Service Tasks. **Do** configure a savepoint **before** -- _Start events_ None Start Event Message Start Event Signal Start Event Timer Start Event: This savepoint allows to immediately return a process instance object to the user thread creating it - well before anything happens in the process instance. +- _Start events_ None Start Event Message Start Event Signal Start Event Timer Start Event: This savepoint allows to immediately return a process instance object to the user thread creating it - well before anything happens in the process instance. -- Service tasks (or other steps) invoking _remote systems_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that you always transactionally separate the potentially more often failing remote calls from anything that happens before such a step. If a service call fails you will observe the process instance waiting in the corresponding service task in cockpit. +- Service tasks (or other steps) invoking _remote systems_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that you always transactionally separate the potentially more often failing remote calls from anything that happens before such a step. If a service call fails you will observe the process instance waiting in the corresponding service task in cockpit. -- _Parallel joins_ Parallel Join Inclusive Join Multiinstance Task: Parallel joins synchronize separate process pathes, which is why one of two path executions arriving at a parallel join at the same time will be rolled back with an optimistic locking exception and must be retryed later on. Therefore such a savepoint makes sure that the path synchronisation will be taken care of by Camunda's internal job executor. Note that for multi instance activities, there exists a dedicated "multi instance asynchronous after" flag which saves every single instance of those multiple instances directly after their execution, hence still "before" their technical synchronization. +- _Parallel joins_ Parallel Join Inclusive Join Multiinstance Task: Parallel joins synchronize separate process pathes, which is why one of two path executions arriving at a parallel join at the same time will be rolled back with an optimistic locking exception and must be retryed later on. Therefore such a savepoint makes sure that the path synchronisation will be taken care of by Camunda's internal job executor. Note that for multi instance activities, there exists a dedicated "multi instance asynchronous after" flag which saves every single instance of those multiple instances directly after their execution, hence still "before" their technical synchronization. The Camunda JobExecutor works (by default) with [exclusive jobs](https://docs.camunda.org/manual/latest/user-guide/process-engine/the-job-executor/#exclusive-jobs), meaning that just one exclusive job per process instance may be executed at once. Hence, job executor threads will by default not cause optimistic locking exceptions at parallel joins "just by themselves", but other threads using the Camunda API might cause them - either for themselves or also for the job executor. **Don't** configure save points **before** -- User tasks and other _wait states_ User Task ScrReceiveipt Task Message Intermediate Event Signal Intermediate Event Timer Intermediate Event Event Based Gateway including steps configured as _external tasks_ Service Task Script Task Send Task Message Intermediate Event Message End Event: Such savepoints just introduce overhead as [wait-states](https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/#wait-states) on itself finish the transaction and wait for external intervention anyway. +- User tasks and other _wait states_ User Task ScrReceiveipt Task Message Intermediate Event Signal Intermediate Event Timer Intermediate Event Event Based Gateway including steps configured as _external tasks_ Service Task Script Task Send Task Message Intermediate Event Message End Event: Such savepoints just introduce overhead as [wait-states](https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/#wait-states) on itself finish the transaction and wait for external intervention anyway. -- _All forking_ and _exclusively joining gateways_ Exclusive Gateway Parallel Join Inclusive Join: There should just be no need to do that, unless execution listeners are configured at such points, which could fail and might need to be transactionally separated from other parts of the execution. +- _All forking_ and _exclusively joining gateways_ Exclusive Gateway Parallel Join Inclusive Join: There should just be no need to do that, unless execution listeners are configured at such points, which could fail and might need to be transactionally separated from other parts of the execution. ### Adding save points automatically to every model diff --git a/versioned_docs/version-8.6/components/best-practices/development/understanding-transaction-handling-c7.md b/versioned_docs/version-8.6/components/best-practices/development/understanding-transaction-handling-c7.md index a22bccca41..9e46442b06 100644 --- a/versioned_docs/version-8.6/components/best-practices/development/understanding-transaction-handling-c7.md +++ b/versioned_docs/version-8.6/components/best-practices/development/understanding-transaction-handling-c7.md @@ -92,27 +92,27 @@ Aside a general strategy to mark service tasks as being save points you will oft - _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. -- Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. +- Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. -- Service tasks (or other steps) executing _expensive Ccmputations_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a computationally expensive step does not have to be repeated just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. +- Service tasks (or other steps) executing _expensive Ccmputations_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a computationally expensive step does not have to be repeated just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. -- Receive tasks (or other steps) catching _external events_, possibly with payload Receive Task Message Intermediate Event Signal Intermediate Event : This savepoint makes sure that a external event like a message is persisted as soon as possible. It cannot get lost just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. This applies also to External Service Tasks. +- Receive tasks (or other steps) catching _external events_, possibly with payload Receive Task Message Intermediate Event Signal Intermediate Event : This savepoint makes sure that a external event like a message is persisted as soon as possible. It cannot get lost just because any subsequent steps might roll back the transaction to a savepoint well before the affected step. This applies also to External Service Tasks. **Do** configure a savepoint **before** -- _Start events_ None Start Event Message Start Event Signal Start Event Timer Start Event: This savepoint allows to immediately return a process instance object to the user thread creating it - well before anything happens in the process instance. +- _Start events_ None Start Event Message Start Event Signal Start Event Timer Start Event: This savepoint allows to immediately return a process instance object to the user thread creating it - well before anything happens in the process instance. -- Service tasks (or other steps) invoking _remote systems_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that you always transactionally separate the potentially more often failing remote calls from anything that happens before such a step. If a service call fails you will observe the process instance waiting in the corresponding service task in cockpit. +- Service tasks (or other steps) invoking _remote systems_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that you always transactionally separate the potentially more often failing remote calls from anything that happens before such a step. If a service call fails you will observe the process instance waiting in the corresponding service task in cockpit. -- _Parallel joins_ Parallel Join Inclusive Join Multiinstance Task: Parallel joins synchronize separate process pathes, which is why one of two path executions arriving at a parallel join at the same time will be rolled back with an optimistic locking exception and must be retryed later on. Therefore such a savepoint makes sure that the path synchronisation will be taken care of by Camunda's internal job executor. Note that for multi instance activities, there exists a dedicated "multi instance asynchronous after" flag which saves every single instance of those multiple instances directly after their execution, hence still "before" their technical synchronization. +- _Parallel joins_ Parallel Join Inclusive Join Multiinstance Task: Parallel joins synchronize separate process pathes, which is why one of two path executions arriving at a parallel join at the same time will be rolled back with an optimistic locking exception and must be retryed later on. Therefore such a savepoint makes sure that the path synchronisation will be taken care of by Camunda's internal job executor. Note that for multi instance activities, there exists a dedicated "multi instance asynchronous after" flag which saves every single instance of those multiple instances directly after their execution, hence still "before" their technical synchronization. The Camunda JobExecutor works (by default) with [exclusive jobs](https://docs.camunda.org/manual/latest/user-guide/process-engine/the-job-executor/#exclusive-jobs), meaning that just one exclusive job per process instance may be executed at once. Hence, job executor threads will by default not cause optimistic locking exceptions at parallel joins "just by themselves", but other threads using the Camunda API might cause them - either for themselves or also for the job executor. **Don't** configure save points **before** -- User tasks and other _wait states_ User Task ScrReceiveipt Task Message Intermediate Event Signal Intermediate Event Timer Intermediate Event Event Based Gateway including steps configured as _external tasks_ Service Task Script Task Send Task Message Intermediate Event Message End Event: Such savepoints just introduce overhead as [wait-states](https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/#wait-states) on itself finish the transaction and wait for external intervention anyway. +- User tasks and other _wait states_ User Task ScrReceiveipt Task Message Intermediate Event Signal Intermediate Event Timer Intermediate Event Event Based Gateway including steps configured as _external tasks_ Service Task Script Task Send Task Message Intermediate Event Message End Event: Such savepoints just introduce overhead as [wait-states](https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/#wait-states) on itself finish the transaction and wait for external intervention anyway. -- _All forking_ and _exclusively joining gateways_ Exclusive Gateway Parallel Join Inclusive Join: There should just be no need to do that, unless execution listeners are configured at such points, which could fail and might need to be transactionally separated from other parts of the execution. +- _All forking_ and _exclusively joining gateways_ Exclusive Gateway Parallel Join Inclusive Join: There should just be no need to do that, unless execution listeners are configured at such points, which could fail and might need to be transactionally separated from other parts of the execution. ### Adding save points automatically to every model From 2273da2477a860ba1f4a545002420d7a74f7722f Mon Sep 17 00:00:00 2001 From: Tim Stawowski Date: Wed, 20 Nov 2024 08:57:26 +0100 Subject: [PATCH 2/2] fix(assets): display bpmn-element images --- .../development/understanding-transaction-handling-c7.md | 2 +- .../development/understanding-transaction-handling-c7.md | 2 +- .../development/understanding-transaction-handling-c7.md | 2 +- .../development/understanding-transaction-handling-c7.md | 2 +- .../development/understanding-transaction-handling-c7.md | 2 +- .../development/understanding-transaction-handling-c7.md | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/components/best-practices/development/understanding-transaction-handling-c7.md b/docs/components/best-practices/development/understanding-transaction-handling-c7.md index 9e46442b06..e5b710d0f2 100644 --- a/docs/components/best-practices/development/understanding-transaction-handling-c7.md +++ b/docs/components/best-practices/development/understanding-transaction-handling-c7.md @@ -90,7 +90,7 @@ Aside a general strategy to mark service tasks as being save points you will oft **Do** configure a savepoint **after** -- _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. +- _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. - Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. diff --git a/versioned_docs/version-8.2/components/best-practices/development/understanding-transaction-handling-c7.md b/versioned_docs/version-8.2/components/best-practices/development/understanding-transaction-handling-c7.md index 391499be37..2310e51dee 100644 --- a/versioned_docs/version-8.2/components/best-practices/development/understanding-transaction-handling-c7.md +++ b/versioned_docs/version-8.2/components/best-practices/development/understanding-transaction-handling-c7.md @@ -90,7 +90,7 @@ Aside a general strategy to mark service tasks as being save points you will oft **Do** configure a savepoint **after** -- _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. +- _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. - Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. diff --git a/versioned_docs/version-8.3/components/best-practices/development/understanding-transaction-handling-c7.md b/versioned_docs/version-8.3/components/best-practices/development/understanding-transaction-handling-c7.md index 03015d612d..5ceeef56cc 100644 --- a/versioned_docs/version-8.3/components/best-practices/development/understanding-transaction-handling-c7.md +++ b/versioned_docs/version-8.3/components/best-practices/development/understanding-transaction-handling-c7.md @@ -90,7 +90,7 @@ Aside a general strategy to mark service tasks as being save points you will oft **Do** configure a savepoint **after** -- _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. +- _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. - Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. diff --git a/versioned_docs/version-8.4/components/best-practices/development/understanding-transaction-handling-c7.md b/versioned_docs/version-8.4/components/best-practices/development/understanding-transaction-handling-c7.md index 4277c0e8cb..3f39f09aaf 100644 --- a/versioned_docs/version-8.4/components/best-practices/development/understanding-transaction-handling-c7.md +++ b/versioned_docs/version-8.4/components/best-practices/development/understanding-transaction-handling-c7.md @@ -90,7 +90,7 @@ Aside a general strategy to mark service tasks as being save points you will oft **Do** configure a savepoint **after** -- _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. +- _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. - Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. diff --git a/versioned_docs/version-8.5/components/best-practices/development/understanding-transaction-handling-c7.md b/versioned_docs/version-8.5/components/best-practices/development/understanding-transaction-handling-c7.md index 4277c0e8cb..3f39f09aaf 100644 --- a/versioned_docs/version-8.5/components/best-practices/development/understanding-transaction-handling-c7.md +++ b/versioned_docs/version-8.5/components/best-practices/development/understanding-transaction-handling-c7.md @@ -90,7 +90,7 @@ Aside a general strategy to mark service tasks as being save points you will oft **Do** configure a savepoint **after** -- _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. +- _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. - Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes. diff --git a/versioned_docs/version-8.6/components/best-practices/development/understanding-transaction-handling-c7.md b/versioned_docs/version-8.6/components/best-practices/development/understanding-transaction-handling-c7.md index 9e46442b06..e5b710d0f2 100644 --- a/versioned_docs/version-8.6/components/best-practices/development/understanding-transaction-handling-c7.md +++ b/versioned_docs/version-8.6/components/best-practices/development/understanding-transaction-handling-c7.md @@ -90,7 +90,7 @@ Aside a general strategy to mark service tasks as being save points you will oft **Do** configure a savepoint **after** -- _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. +- _User tasks_ : This savepoint allows users to complete their tasks without waiting for expensive subsequent steps and without seeing an unexpected rollback of their user transaction to the waitstate before the user task. Sometimes, e.g. when validating user input by means of a subsequent step, you want exactly that: rolling back the user transaction to the user task waitstate. In that case you might want to introduce a savepoint right after the validation step. - Service Tasks (or other steps) causing _Non-idempotent Side Effects_ Service Task Script Task Send Task Message Intermediate Event Message End Event: This savepoint makes sure that a side effect which must not happen more often than once is not accidentally repeated because any subsequent steps might roll back the transaction to a savepoint well before the affected step. End Events should be included if the process can be called from other processes.