[PROPOSAL][WORKFLOW] Transaction in workflow runtime

[Enrique Gonzalez Martinez <eg...@apache.org>]

* Transactions*
This document describes how to support transactions in the domain of
workflow engine and subsystems.

The use cases for transactions in workflows is to enable consistency
during workflow executions.

* Constraints *

The constraints for this are related to different types of transaction problems:

Workflow transaction execution should be in one single transaction
(until idle elements are reached or there are no more elements to
process)

Process state should be consistent in storage in one single
transaction. In the case of database multiple tables should be written
in an atomic transaction

Reactive code should be removed as it does not behave properly with
transactions.

Transactions Policy among workflow runtime and subsystems should be
consistent in terms of configuration (no subcomponent should start a
transaction if there is already one on the go, but they should mandate
to be in a transaction)

Error handling should still produce an event that can be stored.

Subsystems execution should be included during transactions

Async execution will spawn its own transaction.

* Architecture *

The architecture of the solution impacts some areas:

Components with reactive that are involved in transaction refactor. So
far, the only subsystem using reactive code job service.

Process Code generation should change in order to reflect the
transactions of the workflow engine

Error handling should be modified in a way the error is captured
outside the transaction and handled in a different one to avoid event
loss.

Exchange information among runtime and subsystems should be in a way
that those elements are involved in a transaction or they can be
rolled back. At the moment the communication is being done with a rest
call that is not part of the transaction and cannot be rolled back.

Events produced within the transaction should be part of the
transaction as well to avoid phantom events (events producing during
workflow execution that are sent at the end of the unit of work)

* Risk Assessment *

The risks identified for this work are the following:

Error handling can be problematic depending where we set the
boundaries of the transaction. There are two different approaches:

Boilerplate code for each task to start / commit / rollback the
transaction and deail with error in the rest call tier itself

Use the runtime environment to install error handling for doing the operation.

Exchange information among systems in a non-transactional way. There
are a couple of approaches

Install every time a transaction sync listener whenever the rest call
is made against the subsystem and doing a compensation when it fails

Wrap the rest call in a XAResource that can be enlisted in the transaction.

The use of Kafka clients for stream that does not belong to the transactions

Wrap with XAResource (Kafka client support transactions, but does not
offer XAresource)

Install a transaction sync for each transaction.

Performance impact with transactions.

Different transaction methods in quarkus and spring boot

Re: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

[Francisco Javier Tirado Sarti <ft...@redhat.com>]

There are other approaches that do not require integration of Kafka or Rest
into an XA transaction.
One, that I do not particularly like, is to use Outbox pattern(Debezium) (I
do not like it because it requires another process, that is responsible to
send the events, even in sunny day scenarios, and with all the events we
have that going to affect the sunny day scenario performance, which is a
huge problem in my opinion)
Or, the one that I would use, is to use a Debezium like approach, but
without the external process performing the Kafka or Rest call.
The approach will be, for every "transaction".
Sunny day. >  write a log of the operation in the primary BD, the commit,
then write the data in the DB and update the log entry to db written, then
commit in the DB, then t send the event (Rest or Kafka or whatever), once
it is confirmed (thats trivial in Kafka and in REST) that the event has
been dispatches, delete the log in the primary DB.
Rainy day 1 -> the db is down and failed in the operation log commit, we
throw an exception, nothing is written and the user cries, but no
inconsistency.
Rainy daty 2 -> the db goes down between the log commit and the write data
commit. Then it appears the "log checker" (which is a thread or a process
responsible to deal with rainy day situations), it eventually reads the log
and see something goes wrong, but not data has been written in db, so it
deletes the log entry (It is pretty unlikely this escenario ever happen,
but it is anyway covered)
Rainy data 3 -> (the most likely failure when not using kafka) the write
data commit succeeded but when publishing the event something goes wrong
(since Kafka is a db itself, this is not very likely, with http it will
happen more frequently), then the log will remain is state "written to db"
and when the "log checker" is activated, it will realize it has to try to
send the event that was not send. Once it successes on sending the event
(order is relevant here), it will delete the log entry.

What can be wrong? Many things as in any approach ;), the most delicate
escenario is when the log checker fails to delete the log entry after a
successful event sending. This will lead to the same event being published
twice, which is something that also happens with Outbox pattern. The other
problem is to define what to write in the log entry and how to run the log
checker. The main advantage is that sunny day scenario does not require (as
happend with debezium) the external process to send the event from the db
logs. The main disadvantage is that there is an extra write to the db (and
an extra delete).
Why bother to implement this approach if we can integrate REST/Kaka into
Quarkus/Springboot XA? I think this approach captures better the most
likely failing point (sending the event) and does not rollback the whole
operation because the event was not propagated, while at the same time
guarantees it will be eventually propagated.
Why consider this option if we have Outbox? Because on sunny day scenarios
events will be sent as soon as they are available, while in Outbox there is
always a delay (not to mention that the publisher process can go down too,
which adds another piece in the set of possible things that can go wrong).
The overall assumption is that error happens, but does not happen all the
time and we should not substantially decrease performance of sunny days to
cover rainy days if we can.




On Fri, Aug 2, 2024 at 10:09 AM Pere Fernandez (apache) <pe...@apache.org>
wrote:

>  +1 to transactions!
>
> On Fri, 2 Aug 2024 at 08:39, Enrique Gonzalez Martinez <
> egonzalez@apache.org>
> wrote:
>
> > * Transactions*
> > This document describes how to support transactions in the domain of
> > workflow engine and subsystems.
> >
> > The use cases for transactions in workflows is to enable consistency
> > during workflow executions.
> >
> > * Constraints *
> >
> > The constraints for this are related to different types of transaction
> > problems:
> >
> > Workflow transaction execution should be in one single transaction
> > (until idle elements are reached or there are no more elements to
> > process)
> >
> > Process state should be consistent in storage in one single
> > transaction. In the case of database multiple tables should be written
> > in an atomic transaction
> >
> > Reactive code should be removed as it does not behave properly with
> > transactions.
> >
> > Transactions Policy among workflow runtime and subsystems should be
> > consistent in terms of configuration (no subcomponent should start a
> > transaction if there is already one on the go, but they should mandate
> > to be in a transaction)
> >
> > Error handling should still produce an event that can be stored.
> >
> > Subsystems execution should be included during transactions
> >
> > Async execution will spawn its own transaction.
> >
> > * Architecture *
> >
> > The architecture of the solution impacts some areas:
> >
> > Components with reactive that are involved in transaction refactor. So
> > far, the only subsystem using reactive code job service.
> >
> > Process Code generation should change in order to reflect the
> > transactions of the workflow engine
> >
> > Error handling should be modified in a way the error is captured
> > outside the transaction and handled in a different one to avoid event
> > loss.
> >
> > Exchange information among runtime and subsystems should be in a way
> > that those elements are involved in a transaction or they can be
> > rolled back. At the moment the communication is being done with a rest
> > call that is not part of the transaction and cannot be rolled back.
> >
> > Events produced within the transaction should be part of the
> > transaction as well to avoid phantom events (events producing during
> > workflow execution that are sent at the end of the unit of work)
> >
> > * Risk Assessment *
> >
> > The risks identified for this work are the following:
> >
> > Error handling can be problematic depending where we set the
> > boundaries of the transaction. There are two different approaches:
> >
> > Boilerplate code for each task to start / commit / rollback the
> > transaction and deail with error in the rest call tier itself
> >
> > Use the runtime environment to install error handling for doing the
> > operation.
> >
> > Exchange information among systems in a non-transactional way. There
> > are a couple of approaches
> >
> > Install every time a transaction sync listener whenever the rest call
> > is made against the subsystem and doing a compensation when it fails
> >
> > Wrap the rest call in a XAResource that can be enlisted in the
> transaction.
> >
> > The use of Kafka clients for stream that does not belong to the
> > transactions
> >
> > Wrap with XAResource (Kafka client support transactions, but does not
> > offer XAresource)
> >
> > Install a transaction sync for each transaction.
> >
> > Performance impact with transactions.
> >
> > Different transaction methods in quarkus and spring boot
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
>

RE: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

[Martin Weiler <mw...@ibm.com.INVALID>]

+1

________________________________________
From: Jason Porter <li...@apache.org>
Sent: Friday, August 2, 2024 2:25 PM
To: dev@kie.apache.org
Subject: [EXTERNAL] Re: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

I agree for the need of transactions, and welcome the further conversation about how to accomplish it.

On 2024/08/02 11:08:10 Enrique Gonzalez Martinez wrote:
> Spawn a new conversation for that.
>
> El vie, 2 ago 2024, 12:30, Francisco Javier Tirado Sarti <
> ftirados@redhat.com> escribió:
>
> > Ok, I think we all agree we need some kind of transactional behaviour for
> > DB and events (on, in other words, guarantee that events are not lost).
> > Maybe I'm going too fast, but I would like to discuss which are the
> > possible approaches and prioritize them.
> > But, yes, we need to do that
> > Thanks for the clarification.
> >
> > On Fri, Aug 2, 2024 at 12:25 PM Enrique Gonzalez Martinez <
> > elguardian@gmail.com> wrote:
> >
> > > Hi francisco,
> > >
> > > Please go back to the proposal,  I am not setting any custom solutions
> > > just mention in the risk assessment that there are two possible ways
> > > to do this. one with transaction sync and another one with xa
> > > resource.
> > > debezium is ok but still requires transactions and that solution is
> > > based on xa resource as you are using a database to queue the event
> > > that will be sent through kafka.
> > >
> > > Hope it helps. This proposal is about adding transactions not about
> > > how to deal with all possible cases that will come from that. The risk
> > > assessment only identifies the problems and possible solutions.
> > >
> > > Cheers :)
> > >
> > > El vie, 2 ago 2024 a las 12:13, Francisco Javier Tirado Sarti
> > > (<ft...@redhat.com>) escribió:
> > > >
> > > > Sorry to be a PITA and somehow diminish the apparent overall enthusiasm
> > > in
> > > > most of the community, but should we not discuss what we are going to
> > > > really do before voting?
> > > > If for transactions we mean XA transaction, I have to vote -1 till we
> > > > discuss other options.
> > > >
> > > > On Fri, Aug 2, 2024 at 12:05 PM Tibor Zimányi <tz...@apache.org>
> > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > Dňa pi 2. 8. 2024, 12:02 Alex Porcelli <al...@porcelli.me>
> > napísal(a):
> > > > >
> > > > > > +1
> > > > > >
> > > > > > On Fri, Aug 2, 2024 at 4:09 AM Pere Fernandez (apache) <
> > > > > > pefernan@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > >  +1 to transactions!
> > > > > > >
> > > > > > > On Fri, 2 Aug 2024 at 08:39, Enrique Gonzalez Martinez <
> > > > > > > egonzalez@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > * Transactions*
> > > > > > > > This document describes how to support transactions in the
> > > domain of
> > > > > > > > workflow engine and subsystems.
> > > > > > > >
> > > > > > > > The use cases for transactions in workflows is to enable
> > > consistency
> > > > > > > > during workflow executions.
> > > > > > > >
> > > > > > > > * Constraints *
> > > > > > > >
> > > > > > > > The constraints for this are related to different types of
> > > > > transaction
> > > > > > > > problems:
> > > > > > > >
> > > > > > > > Workflow transaction execution should be in one single
> > > transaction
> > > > > > > > (until idle elements are reached or there are no more elements
> > to
> > > > > > > > process)
> > > > > > > >
> > > > > > > > Process state should be consistent in storage in one single
> > > > > > > > transaction. In the case of database multiple tables should be
> > > > > written
> > > > > > > > in an atomic transaction
> > > > > > > >
> > > > > > > > Reactive code should be removed as it does not behave properly
> > > with
> > > > > > > > transactions.
> > > > > > > >
> > > > > > > > Transactions Policy among workflow runtime and subsystems
> > should
> > > be
> > > > > > > > consistent in terms of configuration (no subcomponent should
> > > start a
> > > > > > > > transaction if there is already one on the go, but they should
> > > > > mandate
> > > > > > > > to be in a transaction)
> > > > > > > >
> > > > > > > > Error handling should still produce an event that can be
> > stored.
> > > > > > > >
> > > > > > > > Subsystems execution should be included during transactions
> > > > > > > >
> > > > > > > > Async execution will spawn its own transaction.
> > > > > > > >
> > > > > > > > * Architecture *
> > > > > > > >
> > > > > > > > The architecture of the solution impacts some areas:
> > > > > > > >
> > > > > > > > Components with reactive that are involved in transaction
> > > refactor.
> > > > > So
> > > > > > > > far, the only subsystem using reactive code job service.
> > > > > > > >
> > > > > > > > Process Code generation should change in order to reflect the
> > > > > > > > transactions of the workflow engine
> > > > > > > >
> > > > > > > > Error handling should be modified in a way the error is
> > captured
> > > > > > > > outside the transaction and handled in a different one to avoid
> > > event
> > > > > > > > loss.
> > > > > > > >
> > > > > > > > Exchange information among runtime and subsystems should be in
> > a
> > > way
> > > > > > > > that those elements are involved in a transaction or they can
> > be
> > > > > > > > rolled back. At the moment the communication is being done
> > with a
> > > > > rest
> > > > > > > > call that is not part of the transaction and cannot be rolled
> > > back.
> > > > > > > >
> > > > > > > > Events produced within the transaction should be part of the
> > > > > > > > transaction as well to avoid phantom events (events producing
> > > during
> > > > > > > > workflow execution that are sent at the end of the unit of
> > work)
> > > > > > > >
> > > > > > > > * Risk Assessment *
> > > > > > > >
> > > > > > > > The risks identified for this work are the following:
> > > > > > > >
> > > > > > > > Error handling can be problematic depending where we set the
> > > > > > > > boundaries of the transaction. There are two different
> > > approaches:
> > > > > > > >
> > > > > > > > Boilerplate code for each task to start / commit / rollback the
> > > > > > > > transaction and deail with error in the rest call tier itself
> > > > > > > >
> > > > > > > > Use the runtime environment to install error handling for doing
> > > the
> > > > > > > > operation.
> > > > > > > >
> > > > > > > > Exchange information among systems in a non-transactional way.
> > > There
> > > > > > > > are a couple of approaches
> > > > > > > >
> > > > > > > > Install every time a transaction sync listener whenever the
> > rest
> > > call
> > > > > > > > is made against the subsystem and doing a compensation when it
> > > fails
> > > > > > > >
> > > > > > > > Wrap the rest call in a XAResource that can be enlisted in the
> > > > > > > transaction.
> > > > > > > >
> > > > > > > > The use of Kafka clients for stream that does not belong to the
> > > > > > > > transactions
> > > > > > > >
> > > > > > > > Wrap with XAResource (Kafka client support transactions, but
> > > does not
> > > > > > > > offer XAresource)
> > > > > > > >
> > > > > > > > Install a transaction sync for each transaction.
> > > > > > > >
> > > > > > > > Performance impact with transactions.
> > > > > > > >
> > > > > > > > Different transaction methods in quarkus and spring boot
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > >
> > > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Saludos, Enrique González Martínez :)
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org

Re: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

[Jason Porter <li...@apache.org>]

I agree for the need of transactions, and welcome the further conversation about how to accomplish it.

On 2024/08/02 11:08:10 Enrique Gonzalez Martinez wrote:
> Spawn a new conversation for that.
> 
> El vie, 2 ago 2024, 12:30, Francisco Javier Tirado Sarti <
> ftirados@redhat.com> escribió:
> 
> > Ok, I think we all agree we need some kind of transactional behaviour for
> > DB and events (on, in other words, guarantee that events are not lost).
> > Maybe I'm going too fast, but I would like to discuss which are the
> > possible approaches and prioritize them.
> > But, yes, we need to do that
> > Thanks for the clarification.
> >
> > On Fri, Aug 2, 2024 at 12:25 PM Enrique Gonzalez Martinez <
> > elguardian@gmail.com> wrote:
> >
> > > Hi francisco,
> > >
> > > Please go back to the proposal,  I am not setting any custom solutions
> > > just mention in the risk assessment that there are two possible ways
> > > to do this. one with transaction sync and another one with xa
> > > resource.
> > > debezium is ok but still requires transactions and that solution is
> > > based on xa resource as you are using a database to queue the event
> > > that will be sent through kafka.
> > >
> > > Hope it helps. This proposal is about adding transactions not about
> > > how to deal with all possible cases that will come from that. The risk
> > > assessment only identifies the problems and possible solutions.
> > >
> > > Cheers :)
> > >
> > > El vie, 2 ago 2024 a las 12:13, Francisco Javier Tirado Sarti
> > > (<ft...@redhat.com>) escribió:
> > > >
> > > > Sorry to be a PITA and somehow diminish the apparent overall enthusiasm
> > > in
> > > > most of the community, but should we not discuss what we are going to
> > > > really do before voting?
> > > > If for transactions we mean XA transaction, I have to vote -1 till we
> > > > discuss other options.
> > > >
> > > > On Fri, Aug 2, 2024 at 12:05 PM Tibor Zimányi <tz...@apache.org>
> > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > Dňa pi 2. 8. 2024, 12:02 Alex Porcelli <al...@porcelli.me>
> > napísal(a):
> > > > >
> > > > > > +1
> > > > > >
> > > > > > On Fri, Aug 2, 2024 at 4:09 AM Pere Fernandez (apache) <
> > > > > > pefernan@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > >  +1 to transactions!
> > > > > > >
> > > > > > > On Fri, 2 Aug 2024 at 08:39, Enrique Gonzalez Martinez <
> > > > > > > egonzalez@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > * Transactions*
> > > > > > > > This document describes how to support transactions in the
> > > domain of
> > > > > > > > workflow engine and subsystems.
> > > > > > > >
> > > > > > > > The use cases for transactions in workflows is to enable
> > > consistency
> > > > > > > > during workflow executions.
> > > > > > > >
> > > > > > > > * Constraints *
> > > > > > > >
> > > > > > > > The constraints for this are related to different types of
> > > > > transaction
> > > > > > > > problems:
> > > > > > > >
> > > > > > > > Workflow transaction execution should be in one single
> > > transaction
> > > > > > > > (until idle elements are reached or there are no more elements
> > to
> > > > > > > > process)
> > > > > > > >
> > > > > > > > Process state should be consistent in storage in one single
> > > > > > > > transaction. In the case of database multiple tables should be
> > > > > written
> > > > > > > > in an atomic transaction
> > > > > > > >
> > > > > > > > Reactive code should be removed as it does not behave properly
> > > with
> > > > > > > > transactions.
> > > > > > > >
> > > > > > > > Transactions Policy among workflow runtime and subsystems
> > should
> > > be
> > > > > > > > consistent in terms of configuration (no subcomponent should
> > > start a
> > > > > > > > transaction if there is already one on the go, but they should
> > > > > mandate
> > > > > > > > to be in a transaction)
> > > > > > > >
> > > > > > > > Error handling should still produce an event that can be
> > stored.
> > > > > > > >
> > > > > > > > Subsystems execution should be included during transactions
> > > > > > > >
> > > > > > > > Async execution will spawn its own transaction.
> > > > > > > >
> > > > > > > > * Architecture *
> > > > > > > >
> > > > > > > > The architecture of the solution impacts some areas:
> > > > > > > >
> > > > > > > > Components with reactive that are involved in transaction
> > > refactor.
> > > > > So
> > > > > > > > far, the only subsystem using reactive code job service.
> > > > > > > >
> > > > > > > > Process Code generation should change in order to reflect the
> > > > > > > > transactions of the workflow engine
> > > > > > > >
> > > > > > > > Error handling should be modified in a way the error is
> > captured
> > > > > > > > outside the transaction and handled in a different one to avoid
> > > event
> > > > > > > > loss.
> > > > > > > >
> > > > > > > > Exchange information among runtime and subsystems should be in
> > a
> > > way
> > > > > > > > that those elements are involved in a transaction or they can
> > be
> > > > > > > > rolled back. At the moment the communication is being done
> > with a
> > > > > rest
> > > > > > > > call that is not part of the transaction and cannot be rolled
> > > back.
> > > > > > > >
> > > > > > > > Events produced within the transaction should be part of the
> > > > > > > > transaction as well to avoid phantom events (events producing
> > > during
> > > > > > > > workflow execution that are sent at the end of the unit of
> > work)
> > > > > > > >
> > > > > > > > * Risk Assessment *
> > > > > > > >
> > > > > > > > The risks identified for this work are the following:
> > > > > > > >
> > > > > > > > Error handling can be problematic depending where we set the
> > > > > > > > boundaries of the transaction. There are two different
> > > approaches:
> > > > > > > >
> > > > > > > > Boilerplate code for each task to start / commit / rollback the
> > > > > > > > transaction and deail with error in the rest call tier itself
> > > > > > > >
> > > > > > > > Use the runtime environment to install error handling for doing
> > > the
> > > > > > > > operation.
> > > > > > > >
> > > > > > > > Exchange information among systems in a non-transactional way.
> > > There
> > > > > > > > are a couple of approaches
> > > > > > > >
> > > > > > > > Install every time a transaction sync listener whenever the
> > rest
> > > call
> > > > > > > > is made against the subsystem and doing a compensation when it
> > > fails
> > > > > > > >
> > > > > > > > Wrap the rest call in a XAResource that can be enlisted in the
> > > > > > > transaction.
> > > > > > > >
> > > > > > > > The use of Kafka clients for stream that does not belong to the
> > > > > > > > transactions
> > > > > > > >
> > > > > > > > Wrap with XAResource (Kafka client support transactions, but
> > > does not
> > > > > > > > offer XAresource)
> > > > > > > >
> > > > > > > > Install a transaction sync for each transaction.
> > > > > > > >
> > > > > > > > Performance impact with transactions.
> > > > > > > >
> > > > > > > > Different transaction methods in quarkus and spring boot
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > > >
> > > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Saludos, Enrique González Martínez :)
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> > >
> >
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org

Re: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

[Enrique Gonzalez Martinez <el...@gmail.com>]

Spawn a new conversation for that.

El vie, 2 ago 2024, 12:30, Francisco Javier Tirado Sarti <
ftirados@redhat.com> escribió:

> Ok, I think we all agree we need some kind of transactional behaviour for
> DB and events (on, in other words, guarantee that events are not lost).
> Maybe I'm going too fast, but I would like to discuss which are the
> possible approaches and prioritize them.
> But, yes, we need to do that
> Thanks for the clarification.
>
> On Fri, Aug 2, 2024 at 12:25 PM Enrique Gonzalez Martinez <
> elguardian@gmail.com> wrote:
>
> > Hi francisco,
> >
> > Please go back to the proposal,  I am not setting any custom solutions
> > just mention in the risk assessment that there are two possible ways
> > to do this. one with transaction sync and another one with xa
> > resource.
> > debezium is ok but still requires transactions and that solution is
> > based on xa resource as you are using a database to queue the event
> > that will be sent through kafka.
> >
> > Hope it helps. This proposal is about adding transactions not about
> > how to deal with all possible cases that will come from that. The risk
> > assessment only identifies the problems and possible solutions.
> >
> > Cheers :)
> >
> > El vie, 2 ago 2024 a las 12:13, Francisco Javier Tirado Sarti
> > (<ft...@redhat.com>) escribió:
> > >
> > > Sorry to be a PITA and somehow diminish the apparent overall enthusiasm
> > in
> > > most of the community, but should we not discuss what we are going to
> > > really do before voting?
> > > If for transactions we mean XA transaction, I have to vote -1 till we
> > > discuss other options.
> > >
> > > On Fri, Aug 2, 2024 at 12:05 PM Tibor Zimányi <tz...@apache.org>
> > wrote:
> > >
> > > > +1
> > > >
> > > > Dňa pi 2. 8. 2024, 12:02 Alex Porcelli <al...@porcelli.me>
> napísal(a):
> > > >
> > > > > +1
> > > > >
> > > > > On Fri, Aug 2, 2024 at 4:09 AM Pere Fernandez (apache) <
> > > > > pefernan@apache.org>
> > > > > wrote:
> > > > >
> > > > > >  +1 to transactions!
> > > > > >
> > > > > > On Fri, 2 Aug 2024 at 08:39, Enrique Gonzalez Martinez <
> > > > > > egonzalez@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > * Transactions*
> > > > > > > This document describes how to support transactions in the
> > domain of
> > > > > > > workflow engine and subsystems.
> > > > > > >
> > > > > > > The use cases for transactions in workflows is to enable
> > consistency
> > > > > > > during workflow executions.
> > > > > > >
> > > > > > > * Constraints *
> > > > > > >
> > > > > > > The constraints for this are related to different types of
> > > > transaction
> > > > > > > problems:
> > > > > > >
> > > > > > > Workflow transaction execution should be in one single
> > transaction
> > > > > > > (until idle elements are reached or there are no more elements
> to
> > > > > > > process)
> > > > > > >
> > > > > > > Process state should be consistent in storage in one single
> > > > > > > transaction. In the case of database multiple tables should be
> > > > written
> > > > > > > in an atomic transaction
> > > > > > >
> > > > > > > Reactive code should be removed as it does not behave properly
> > with
> > > > > > > transactions.
> > > > > > >
> > > > > > > Transactions Policy among workflow runtime and subsystems
> should
> > be
> > > > > > > consistent in terms of configuration (no subcomponent should
> > start a
> > > > > > > transaction if there is already one on the go, but they should
> > > > mandate
> > > > > > > to be in a transaction)
> > > > > > >
> > > > > > > Error handling should still produce an event that can be
> stored.
> > > > > > >
> > > > > > > Subsystems execution should be included during transactions
> > > > > > >
> > > > > > > Async execution will spawn its own transaction.
> > > > > > >
> > > > > > > * Architecture *
> > > > > > >
> > > > > > > The architecture of the solution impacts some areas:
> > > > > > >
> > > > > > > Components with reactive that are involved in transaction
> > refactor.
> > > > So
> > > > > > > far, the only subsystem using reactive code job service.
> > > > > > >
> > > > > > > Process Code generation should change in order to reflect the
> > > > > > > transactions of the workflow engine
> > > > > > >
> > > > > > > Error handling should be modified in a way the error is
> captured
> > > > > > > outside the transaction and handled in a different one to avoid
> > event
> > > > > > > loss.
> > > > > > >
> > > > > > > Exchange information among runtime and subsystems should be in
> a
> > way
> > > > > > > that those elements are involved in a transaction or they can
> be
> > > > > > > rolled back. At the moment the communication is being done
> with a
> > > > rest
> > > > > > > call that is not part of the transaction and cannot be rolled
> > back.
> > > > > > >
> > > > > > > Events produced within the transaction should be part of the
> > > > > > > transaction as well to avoid phantom events (events producing
> > during
> > > > > > > workflow execution that are sent at the end of the unit of
> work)
> > > > > > >
> > > > > > > * Risk Assessment *
> > > > > > >
> > > > > > > The risks identified for this work are the following:
> > > > > > >
> > > > > > > Error handling can be problematic depending where we set the
> > > > > > > boundaries of the transaction. There are two different
> > approaches:
> > > > > > >
> > > > > > > Boilerplate code for each task to start / commit / rollback the
> > > > > > > transaction and deail with error in the rest call tier itself
> > > > > > >
> > > > > > > Use the runtime environment to install error handling for doing
> > the
> > > > > > > operation.
> > > > > > >
> > > > > > > Exchange information among systems in a non-transactional way.
> > There
> > > > > > > are a couple of approaches
> > > > > > >
> > > > > > > Install every time a transaction sync listener whenever the
> rest
> > call
> > > > > > > is made against the subsystem and doing a compensation when it
> > fails
> > > > > > >
> > > > > > > Wrap the rest call in a XAResource that can be enlisted in the
> > > > > > transaction.
> > > > > > >
> > > > > > > The use of Kafka clients for stream that does not belong to the
> > > > > > > transactions
> > > > > > >
> > > > > > > Wrap with XAResource (Kafka client support transactions, but
> > does not
> > > > > > > offer XAresource)
> > > > > > >
> > > > > > > Install a transaction sync for each transaction.
> > > > > > >
> > > > > > > Performance impact with transactions.
> > > > > > >
> > > > > > > Different transaction methods in quarkus and spring boot
> > > > > > >
> > > > > > >
> > > > > > >
> > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > > >
> > > > >
> > > >
> >
> >
> >
> > --
> > Saludos, Enrique González Martínez :)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
>

Re: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

[Francisco Javier Tirado Sarti <ft...@redhat.com>]

Ok, I think we all agree we need some kind of transactional behaviour for
DB and events (on, in other words, guarantee that events are not lost).
Maybe I'm going too fast, but I would like to discuss which are the
possible approaches and prioritize them.
But, yes, we need to do that
Thanks for the clarification.

On Fri, Aug 2, 2024 at 12:25 PM Enrique Gonzalez Martinez <
elguardian@gmail.com> wrote:

> Hi francisco,
>
> Please go back to the proposal,  I am not setting any custom solutions
> just mention in the risk assessment that there are two possible ways
> to do this. one with transaction sync and another one with xa
> resource.
> debezium is ok but still requires transactions and that solution is
> based on xa resource as you are using a database to queue the event
> that will be sent through kafka.
>
> Hope it helps. This proposal is about adding transactions not about
> how to deal with all possible cases that will come from that. The risk
> assessment only identifies the problems and possible solutions.
>
> Cheers :)
>
> El vie, 2 ago 2024 a las 12:13, Francisco Javier Tirado Sarti
> (<ft...@redhat.com>) escribió:
> >
> > Sorry to be a PITA and somehow diminish the apparent overall enthusiasm
> in
> > most of the community, but should we not discuss what we are going to
> > really do before voting?
> > If for transactions we mean XA transaction, I have to vote -1 till we
> > discuss other options.
> >
> > On Fri, Aug 2, 2024 at 12:05 PM Tibor Zimányi <tz...@apache.org>
> wrote:
> >
> > > +1
> > >
> > > Dňa pi 2. 8. 2024, 12:02 Alex Porcelli <al...@porcelli.me> napísal(a):
> > >
> > > > +1
> > > >
> > > > On Fri, Aug 2, 2024 at 4:09 AM Pere Fernandez (apache) <
> > > > pefernan@apache.org>
> > > > wrote:
> > > >
> > > > >  +1 to transactions!
> > > > >
> > > > > On Fri, 2 Aug 2024 at 08:39, Enrique Gonzalez Martinez <
> > > > > egonzalez@apache.org>
> > > > > wrote:
> > > > >
> > > > > > * Transactions*
> > > > > > This document describes how to support transactions in the
> domain of
> > > > > > workflow engine and subsystems.
> > > > > >
> > > > > > The use cases for transactions in workflows is to enable
> consistency
> > > > > > during workflow executions.
> > > > > >
> > > > > > * Constraints *
> > > > > >
> > > > > > The constraints for this are related to different types of
> > > transaction
> > > > > > problems:
> > > > > >
> > > > > > Workflow transaction execution should be in one single
> transaction
> > > > > > (until idle elements are reached or there are no more elements to
> > > > > > process)
> > > > > >
> > > > > > Process state should be consistent in storage in one single
> > > > > > transaction. In the case of database multiple tables should be
> > > written
> > > > > > in an atomic transaction
> > > > > >
> > > > > > Reactive code should be removed as it does not behave properly
> with
> > > > > > transactions.
> > > > > >
> > > > > > Transactions Policy among workflow runtime and subsystems should
> be
> > > > > > consistent in terms of configuration (no subcomponent should
> start a
> > > > > > transaction if there is already one on the go, but they should
> > > mandate
> > > > > > to be in a transaction)
> > > > > >
> > > > > > Error handling should still produce an event that can be stored.
> > > > > >
> > > > > > Subsystems execution should be included during transactions
> > > > > >
> > > > > > Async execution will spawn its own transaction.
> > > > > >
> > > > > > * Architecture *
> > > > > >
> > > > > > The architecture of the solution impacts some areas:
> > > > > >
> > > > > > Components with reactive that are involved in transaction
> refactor.
> > > So
> > > > > > far, the only subsystem using reactive code job service.
> > > > > >
> > > > > > Process Code generation should change in order to reflect the
> > > > > > transactions of the workflow engine
> > > > > >
> > > > > > Error handling should be modified in a way the error is captured
> > > > > > outside the transaction and handled in a different one to avoid
> event
> > > > > > loss.
> > > > > >
> > > > > > Exchange information among runtime and subsystems should be in a
> way
> > > > > > that those elements are involved in a transaction or they can be
> > > > > > rolled back. At the moment the communication is being done with a
> > > rest
> > > > > > call that is not part of the transaction and cannot be rolled
> back.
> > > > > >
> > > > > > Events produced within the transaction should be part of the
> > > > > > transaction as well to avoid phantom events (events producing
> during
> > > > > > workflow execution that are sent at the end of the unit of work)
> > > > > >
> > > > > > * Risk Assessment *
> > > > > >
> > > > > > The risks identified for this work are the following:
> > > > > >
> > > > > > Error handling can be problematic depending where we set the
> > > > > > boundaries of the transaction. There are two different
> approaches:
> > > > > >
> > > > > > Boilerplate code for each task to start / commit / rollback the
> > > > > > transaction and deail with error in the rest call tier itself
> > > > > >
> > > > > > Use the runtime environment to install error handling for doing
> the
> > > > > > operation.
> > > > > >
> > > > > > Exchange information among systems in a non-transactional way.
> There
> > > > > > are a couple of approaches
> > > > > >
> > > > > > Install every time a transaction sync listener whenever the rest
> call
> > > > > > is made against the subsystem and doing a compensation when it
> fails
> > > > > >
> > > > > > Wrap the rest call in a XAResource that can be enlisted in the
> > > > > transaction.
> > > > > >
> > > > > > The use of Kafka clients for stream that does not belong to the
> > > > > > transactions
> > > > > >
> > > > > > Wrap with XAResource (Kafka client support transactions, but
> does not
> > > > > > offer XAresource)
> > > > > >
> > > > > > Install a transaction sync for each transaction.
> > > > > >
> > > > > > Performance impact with transactions.
> > > > > >
> > > > > > Different transaction methods in quarkus and spring boot
> > > > > >
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > > >
> > > >
> > >
>
>
>
> --
> Saludos, Enrique González Martínez :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>

Re: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

[Enrique Gonzalez Martinez <el...@gmail.com>]

Hi francisco,

Please go back to the proposal,  I am not setting any custom solutions
just mention in the risk assessment that there are two possible ways
to do this. one with transaction sync and another one with xa
resource.
debezium is ok but still requires transactions and that solution is
based on xa resource as you are using a database to queue the event
that will be sent through kafka.

Hope it helps. This proposal is about adding transactions not about
how to deal with all possible cases that will come from that. The risk
assessment only identifies the problems and possible solutions.

Cheers :)

El vie, 2 ago 2024 a las 12:13, Francisco Javier Tirado Sarti
(<ft...@redhat.com>) escribió:
>
> Sorry to be a PITA and somehow diminish the apparent overall enthusiasm in
> most of the community, but should we not discuss what we are going to
> really do before voting?
> If for transactions we mean XA transaction, I have to vote -1 till we
> discuss other options.
>
> On Fri, Aug 2, 2024 at 12:05 PM Tibor Zimányi <tz...@apache.org> wrote:
>
> > +1
> >
> > Dňa pi 2. 8. 2024, 12:02 Alex Porcelli <al...@porcelli.me> napísal(a):
> >
> > > +1
> > >
> > > On Fri, Aug 2, 2024 at 4:09 AM Pere Fernandez (apache) <
> > > pefernan@apache.org>
> > > wrote:
> > >
> > > >  +1 to transactions!
> > > >
> > > > On Fri, 2 Aug 2024 at 08:39, Enrique Gonzalez Martinez <
> > > > egonzalez@apache.org>
> > > > wrote:
> > > >
> > > > > * Transactions*
> > > > > This document describes how to support transactions in the domain of
> > > > > workflow engine and subsystems.
> > > > >
> > > > > The use cases for transactions in workflows is to enable consistency
> > > > > during workflow executions.
> > > > >
> > > > > * Constraints *
> > > > >
> > > > > The constraints for this are related to different types of
> > transaction
> > > > > problems:
> > > > >
> > > > > Workflow transaction execution should be in one single transaction
> > > > > (until idle elements are reached or there are no more elements to
> > > > > process)
> > > > >
> > > > > Process state should be consistent in storage in one single
> > > > > transaction. In the case of database multiple tables should be
> > written
> > > > > in an atomic transaction
> > > > >
> > > > > Reactive code should be removed as it does not behave properly with
> > > > > transactions.
> > > > >
> > > > > Transactions Policy among workflow runtime and subsystems should be
> > > > > consistent in terms of configuration (no subcomponent should start a
> > > > > transaction if there is already one on the go, but they should
> > mandate
> > > > > to be in a transaction)
> > > > >
> > > > > Error handling should still produce an event that can be stored.
> > > > >
> > > > > Subsystems execution should be included during transactions
> > > > >
> > > > > Async execution will spawn its own transaction.
> > > > >
> > > > > * Architecture *
> > > > >
> > > > > The architecture of the solution impacts some areas:
> > > > >
> > > > > Components with reactive that are involved in transaction refactor.
> > So
> > > > > far, the only subsystem using reactive code job service.
> > > > >
> > > > > Process Code generation should change in order to reflect the
> > > > > transactions of the workflow engine
> > > > >
> > > > > Error handling should be modified in a way the error is captured
> > > > > outside the transaction and handled in a different one to avoid event
> > > > > loss.
> > > > >
> > > > > Exchange information among runtime and subsystems should be in a way
> > > > > that those elements are involved in a transaction or they can be
> > > > > rolled back. At the moment the communication is being done with a
> > rest
> > > > > call that is not part of the transaction and cannot be rolled back.
> > > > >
> > > > > Events produced within the transaction should be part of the
> > > > > transaction as well to avoid phantom events (events producing during
> > > > > workflow execution that are sent at the end of the unit of work)
> > > > >
> > > > > * Risk Assessment *
> > > > >
> > > > > The risks identified for this work are the following:
> > > > >
> > > > > Error handling can be problematic depending where we set the
> > > > > boundaries of the transaction. There are two different approaches:
> > > > >
> > > > > Boilerplate code for each task to start / commit / rollback the
> > > > > transaction and deail with error in the rest call tier itself
> > > > >
> > > > > Use the runtime environment to install error handling for doing the
> > > > > operation.
> > > > >
> > > > > Exchange information among systems in a non-transactional way. There
> > > > > are a couple of approaches
> > > > >
> > > > > Install every time a transaction sync listener whenever the rest call
> > > > > is made against the subsystem and doing a compensation when it fails
> > > > >
> > > > > Wrap the rest call in a XAResource that can be enlisted in the
> > > > transaction.
> > > > >
> > > > > The use of Kafka clients for stream that does not belong to the
> > > > > transactions
> > > > >
> > > > > Wrap with XAResource (Kafka client support transactions, but does not
> > > > > offer XAresource)
> > > > >
> > > > > Install a transaction sync for each transaction.
> > > > >
> > > > > Performance impact with transactions.
> > > > >
> > > > > Different transaction methods in quarkus and spring boot
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > >
> >



-- 
Saludos, Enrique González Martínez :)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org

Re: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

[Francisco Javier Tirado Sarti <ft...@redhat.com>]

Sorry to be a PITA and somehow diminish the apparent overall enthusiasm in
most of the community, but should we not discuss what we are going to
really do before voting?
If for transactions we mean XA transaction, I have to vote -1 till we
discuss other options.

On Fri, Aug 2, 2024 at 12:05 PM Tibor Zimányi <tz...@apache.org> wrote:

> +1
>
> Dňa pi 2. 8. 2024, 12:02 Alex Porcelli <al...@porcelli.me> napísal(a):
>
> > +1
> >
> > On Fri, Aug 2, 2024 at 4:09 AM Pere Fernandez (apache) <
> > pefernan@apache.org>
> > wrote:
> >
> > >  +1 to transactions!
> > >
> > > On Fri, 2 Aug 2024 at 08:39, Enrique Gonzalez Martinez <
> > > egonzalez@apache.org>
> > > wrote:
> > >
> > > > * Transactions*
> > > > This document describes how to support transactions in the domain of
> > > > workflow engine and subsystems.
> > > >
> > > > The use cases for transactions in workflows is to enable consistency
> > > > during workflow executions.
> > > >
> > > > * Constraints *
> > > >
> > > > The constraints for this are related to different types of
> transaction
> > > > problems:
> > > >
> > > > Workflow transaction execution should be in one single transaction
> > > > (until idle elements are reached or there are no more elements to
> > > > process)
> > > >
> > > > Process state should be consistent in storage in one single
> > > > transaction. In the case of database multiple tables should be
> written
> > > > in an atomic transaction
> > > >
> > > > Reactive code should be removed as it does not behave properly with
> > > > transactions.
> > > >
> > > > Transactions Policy among workflow runtime and subsystems should be
> > > > consistent in terms of configuration (no subcomponent should start a
> > > > transaction if there is already one on the go, but they should
> mandate
> > > > to be in a transaction)
> > > >
> > > > Error handling should still produce an event that can be stored.
> > > >
> > > > Subsystems execution should be included during transactions
> > > >
> > > > Async execution will spawn its own transaction.
> > > >
> > > > * Architecture *
> > > >
> > > > The architecture of the solution impacts some areas:
> > > >
> > > > Components with reactive that are involved in transaction refactor.
> So
> > > > far, the only subsystem using reactive code job service.
> > > >
> > > > Process Code generation should change in order to reflect the
> > > > transactions of the workflow engine
> > > >
> > > > Error handling should be modified in a way the error is captured
> > > > outside the transaction and handled in a different one to avoid event
> > > > loss.
> > > >
> > > > Exchange information among runtime and subsystems should be in a way
> > > > that those elements are involved in a transaction or they can be
> > > > rolled back. At the moment the communication is being done with a
> rest
> > > > call that is not part of the transaction and cannot be rolled back.
> > > >
> > > > Events produced within the transaction should be part of the
> > > > transaction as well to avoid phantom events (events producing during
> > > > workflow execution that are sent at the end of the unit of work)
> > > >
> > > > * Risk Assessment *
> > > >
> > > > The risks identified for this work are the following:
> > > >
> > > > Error handling can be problematic depending where we set the
> > > > boundaries of the transaction. There are two different approaches:
> > > >
> > > > Boilerplate code for each task to start / commit / rollback the
> > > > transaction and deail with error in the rest call tier itself
> > > >
> > > > Use the runtime environment to install error handling for doing the
> > > > operation.
> > > >
> > > > Exchange information among systems in a non-transactional way. There
> > > > are a couple of approaches
> > > >
> > > > Install every time a transaction sync listener whenever the rest call
> > > > is made against the subsystem and doing a compensation when it fails
> > > >
> > > > Wrap the rest call in a XAResource that can be enlisted in the
> > > transaction.
> > > >
> > > > The use of Kafka clients for stream that does not belong to the
> > > > transactions
> > > >
> > > > Wrap with XAResource (Kafka client support transactions, but does not
> > > > offer XAresource)
> > > >
> > > > Install a transaction sync for each transaction.
> > > >
> > > > Performance impact with transactions.
> > > >
> > > > Different transaction methods in quarkus and spring boot
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> >
>

Re: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

[Tibor Zimányi <tz...@apache.org>]

+1

Dňa pi 2. 8. 2024, 12:02 Alex Porcelli <al...@porcelli.me> napísal(a):

> +1
>
> On Fri, Aug 2, 2024 at 4:09 AM Pere Fernandez (apache) <
> pefernan@apache.org>
> wrote:
>
> >  +1 to transactions!
> >
> > On Fri, 2 Aug 2024 at 08:39, Enrique Gonzalez Martinez <
> > egonzalez@apache.org>
> > wrote:
> >
> > > * Transactions*
> > > This document describes how to support transactions in the domain of
> > > workflow engine and subsystems.
> > >
> > > The use cases for transactions in workflows is to enable consistency
> > > during workflow executions.
> > >
> > > * Constraints *
> > >
> > > The constraints for this are related to different types of transaction
> > > problems:
> > >
> > > Workflow transaction execution should be in one single transaction
> > > (until idle elements are reached or there are no more elements to
> > > process)
> > >
> > > Process state should be consistent in storage in one single
> > > transaction. In the case of database multiple tables should be written
> > > in an atomic transaction
> > >
> > > Reactive code should be removed as it does not behave properly with
> > > transactions.
> > >
> > > Transactions Policy among workflow runtime and subsystems should be
> > > consistent in terms of configuration (no subcomponent should start a
> > > transaction if there is already one on the go, but they should mandate
> > > to be in a transaction)
> > >
> > > Error handling should still produce an event that can be stored.
> > >
> > > Subsystems execution should be included during transactions
> > >
> > > Async execution will spawn its own transaction.
> > >
> > > * Architecture *
> > >
> > > The architecture of the solution impacts some areas:
> > >
> > > Components with reactive that are involved in transaction refactor. So
> > > far, the only subsystem using reactive code job service.
> > >
> > > Process Code generation should change in order to reflect the
> > > transactions of the workflow engine
> > >
> > > Error handling should be modified in a way the error is captured
> > > outside the transaction and handled in a different one to avoid event
> > > loss.
> > >
> > > Exchange information among runtime and subsystems should be in a way
> > > that those elements are involved in a transaction or they can be
> > > rolled back. At the moment the communication is being done with a rest
> > > call that is not part of the transaction and cannot be rolled back.
> > >
> > > Events produced within the transaction should be part of the
> > > transaction as well to avoid phantom events (events producing during
> > > workflow execution that are sent at the end of the unit of work)
> > >
> > > * Risk Assessment *
> > >
> > > The risks identified for this work are the following:
> > >
> > > Error handling can be problematic depending where we set the
> > > boundaries of the transaction. There are two different approaches:
> > >
> > > Boilerplate code for each task to start / commit / rollback the
> > > transaction and deail with error in the rest call tier itself
> > >
> > > Use the runtime environment to install error handling for doing the
> > > operation.
> > >
> > > Exchange information among systems in a non-transactional way. There
> > > are a couple of approaches
> > >
> > > Install every time a transaction sync listener whenever the rest call
> > > is made against the subsystem and doing a compensation when it fails
> > >
> > > Wrap the rest call in a XAResource that can be enlisted in the
> > transaction.
> > >
> > > The use of Kafka clients for stream that does not belong to the
> > > transactions
> > >
> > > Wrap with XAResource (Kafka client support transactions, but does not
> > > offer XAresource)
> > >
> > > Install a transaction sync for each transaction.
> > >
> > > Performance impact with transactions.
> > >
> > > Different transaction methods in quarkus and spring boot
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> >
>

Re: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

[Alex Porcelli <al...@porcelli.me>]

+1

On Fri, Aug 2, 2024 at 4:09 AM Pere Fernandez (apache) <pe...@apache.org>
wrote:

>  +1 to transactions!
>
> On Fri, 2 Aug 2024 at 08:39, Enrique Gonzalez Martinez <
> egonzalez@apache.org>
> wrote:
>
> > * Transactions*
> > This document describes how to support transactions in the domain of
> > workflow engine and subsystems.
> >
> > The use cases for transactions in workflows is to enable consistency
> > during workflow executions.
> >
> > * Constraints *
> >
> > The constraints for this are related to different types of transaction
> > problems:
> >
> > Workflow transaction execution should be in one single transaction
> > (until idle elements are reached or there are no more elements to
> > process)
> >
> > Process state should be consistent in storage in one single
> > transaction. In the case of database multiple tables should be written
> > in an atomic transaction
> >
> > Reactive code should be removed as it does not behave properly with
> > transactions.
> >
> > Transactions Policy among workflow runtime and subsystems should be
> > consistent in terms of configuration (no subcomponent should start a
> > transaction if there is already one on the go, but they should mandate
> > to be in a transaction)
> >
> > Error handling should still produce an event that can be stored.
> >
> > Subsystems execution should be included during transactions
> >
> > Async execution will spawn its own transaction.
> >
> > * Architecture *
> >
> > The architecture of the solution impacts some areas:
> >
> > Components with reactive that are involved in transaction refactor. So
> > far, the only subsystem using reactive code job service.
> >
> > Process Code generation should change in order to reflect the
> > transactions of the workflow engine
> >
> > Error handling should be modified in a way the error is captured
> > outside the transaction and handled in a different one to avoid event
> > loss.
> >
> > Exchange information among runtime and subsystems should be in a way
> > that those elements are involved in a transaction or they can be
> > rolled back. At the moment the communication is being done with a rest
> > call that is not part of the transaction and cannot be rolled back.
> >
> > Events produced within the transaction should be part of the
> > transaction as well to avoid phantom events (events producing during
> > workflow execution that are sent at the end of the unit of work)
> >
> > * Risk Assessment *
> >
> > The risks identified for this work are the following:
> >
> > Error handling can be problematic depending where we set the
> > boundaries of the transaction. There are two different approaches:
> >
> > Boilerplate code for each task to start / commit / rollback the
> > transaction and deail with error in the rest call tier itself
> >
> > Use the runtime environment to install error handling for doing the
> > operation.
> >
> > Exchange information among systems in a non-transactional way. There
> > are a couple of approaches
> >
> > Install every time a transaction sync listener whenever the rest call
> > is made against the subsystem and doing a compensation when it fails
> >
> > Wrap the rest call in a XAResource that can be enlisted in the
> transaction.
> >
> > The use of Kafka clients for stream that does not belong to the
> > transactions
> >
> > Wrap with XAResource (Kafka client support transactions, but does not
> > offer XAresource)
> >
> > Install a transaction sync for each transaction.
> >
> > Performance impact with transactions.
> >
> > Different transaction methods in quarkus and spring boot
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
>

Re: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

["Pere Fernandez (apache)" <pe...@apache.org>]

 +1 to transactions!

On Fri, 2 Aug 2024 at 08:39, Enrique Gonzalez Martinez <eg...@apache.org>
wrote:

> * Transactions*
> This document describes how to support transactions in the domain of
> workflow engine and subsystems.
>
> The use cases for transactions in workflows is to enable consistency
> during workflow executions.
>
> * Constraints *
>
> The constraints for this are related to different types of transaction
> problems:
>
> Workflow transaction execution should be in one single transaction
> (until idle elements are reached or there are no more elements to
> process)
>
> Process state should be consistent in storage in one single
> transaction. In the case of database multiple tables should be written
> in an atomic transaction
>
> Reactive code should be removed as it does not behave properly with
> transactions.
>
> Transactions Policy among workflow runtime and subsystems should be
> consistent in terms of configuration (no subcomponent should start a
> transaction if there is already one on the go, but they should mandate
> to be in a transaction)
>
> Error handling should still produce an event that can be stored.
>
> Subsystems execution should be included during transactions
>
> Async execution will spawn its own transaction.
>
> * Architecture *
>
> The architecture of the solution impacts some areas:
>
> Components with reactive that are involved in transaction refactor. So
> far, the only subsystem using reactive code job service.
>
> Process Code generation should change in order to reflect the
> transactions of the workflow engine
>
> Error handling should be modified in a way the error is captured
> outside the transaction and handled in a different one to avoid event
> loss.
>
> Exchange information among runtime and subsystems should be in a way
> that those elements are involved in a transaction or they can be
> rolled back. At the moment the communication is being done with a rest
> call that is not part of the transaction and cannot be rolled back.
>
> Events produced within the transaction should be part of the
> transaction as well to avoid phantom events (events producing during
> workflow execution that are sent at the end of the unit of work)
>
> * Risk Assessment *
>
> The risks identified for this work are the following:
>
> Error handling can be problematic depending where we set the
> boundaries of the transaction. There are two different approaches:
>
> Boilerplate code for each task to start / commit / rollback the
> transaction and deail with error in the rest call tier itself
>
> Use the runtime environment to install error handling for doing the
> operation.
>
> Exchange information among systems in a non-transactional way. There
> are a couple of approaches
>
> Install every time a transaction sync listener whenever the rest call
> is made against the subsystem and doing a compensation when it fails
>
> Wrap the rest call in a XAResource that can be enlisted in the transaction.
>
> The use of Kafka clients for stream that does not belong to the
> transactions
>
> Wrap with XAResource (Kafka client support transactions, but does not
> offer XAresource)
>
> Install a transaction sync for each transaction.
>
> Performance impact with transactions.
>
> Different transaction methods in quarkus and spring boot
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org

Re: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

[Alex Porcelli <al...@porcelli.me>]

Thank you for the clarifications, Enrique.

It sounds not only reasonable, but critical when running in the
same deployment unit runtime and data-index (same would apply for other
services running co-located).

On Wed, Aug 7, 2024 at 1:04 PM Enrique Gonzalez Martinez <
elguardian@gmail.com> wrote:

> Inline answers
>
> El mié, 7 ago 2024 a las 18:35, Kris Verlaenen
> (<kr...@gmail.com>) escribió:
> >
> > I share the concern with Francisco that we should be careful that we
> don't
> > introduce a solution that would require a distributed transaction to
> > guarantee consistency, there are other approaches that might be
> sufficient
> > or that deliver eventual consistency that I think we should allow.
> >
>
> I have never talked about distributed transactions. (if you understand
> them we need to export transactions from the runtime to the data index
> during execution in a distributed deployment).
>
> Transaction in this context means an operation execution within the
> deployment.
> We need transactions as several writes to the database are performed
> during the same workflow execution. There is no other way to guarantee
> consistency than using transactions.
> XA (2 phase commit transactions) within the same deployment is
> regarding some parts of the system that might write to different
> databases. For instance runtime + data index or runtime + data audit.
> Therefore the 2 phases commit transactions.
>
> > I have a few questions:
> >  * Could you clarify what you mean with subsystems?  Because depending on
> > your architecture I guess this could be different (for example you could
> > run a job service embedded or as a separate service).
>
> Subsystems are all those services required or optional that add
> functionality to the engine. jobs, data index, data audit, user tasks.
>
> > One could argue that
> > the work of another system does not have to be done as part of the same
> > transaction if the communication with that other system is done in a
> > guaranteed way?  Or do we consider those not a subsystem in that case?
>
> The transaction is not being exported or imported from one deployment
> to another (never talked about that). The only thing we want to
> guarantee is that an operation within the same deployment is
> consistent. If that requirement is met all systems will be eventually
> consistent.
> e.g
>
> Runtime executes an operation and sends events to kafka. This is a
> transaction within the same deployment and it is consistent in
> runtime.
> Data index consumes the event from kafka to the storage. This is
> another transaction within data index deployment.
>
> There are two different transactions. They are not the same
> transaction but within the deployment they are consistent. and among
> systems they will be eventually consistent as data indexes will end up
> consuming the event.
>
>
> >  * For some external services it might not be required to be part of a
> > transaction?  For example if you're just querying some information it
> might
> > be totally acceptable to do this REST invocation directly and outside a
> > transaction.
>
> Which system are you referring to ? For now the only invocation we
> have within the engine is job service, so Rest cannot be outside the
> transaction as the engine requires information exchange (we send the
> data to create the timer and we get the job id).
> If you are talking about service tasks (WIH) the author will have to
> decide if it is querying or just need to create a compensation
> mechanism.
>
> > Similarly, it might be fine to send out events directly,
> > there might be other ways to compensate or ignore events later if
> necessary.
>
> If you try to compensate for events in a bpmn you will tie the design
> of the workflow to the environments. So there won't be any point in
> the abstraction itself of the process.
> Phantom events or Duplication events are off the table in bpmn as it
> can impact the workflow execution. Serverless workflow might be more
> tolerant in those abstractions but I guess that if a workflow receives
> a phantom signal or event and executes it, I can make a guess it won't
> be any good.
>
> >  * It's unclear to me how this interacts with the unit of work.  The idea
> > of the unit of work is to collect all the changes, and then apply them
> all
> > at once towards the end.
>
> it does not matter how the unit of work does things. The unit of work
> is not everything that happens in an execution (e.g correlation
> service, messaging, jobs, index, audit....).
> The interaction is about operations invoked against the engine.
>
> > This way you could have different implementations
> > of the unit of work.  Is transactions a specific implementation of the
> unit
> > of work where you start/commit a transaction when the unit of work is
> > started/ended?  And another alternative would be we write everything to a
> > single data source, and use the outbox pattern or similar for further
> > processing?
>
> That won't do per unit of work impl limitation. (see my previous comment).
> Even if you have a single data source you write several times in
> several tables, so you need transactions to keep consistency.
>
> >
> > Thx,
> > Kris
> >
> >
> > On Fri, Aug 2, 2024 at 8:39 AM Enrique Gonzalez Martinez <
> > egonzalez@apache.org> wrote:
> >
> > > * Transactions*
> > > This document describes how to support transactions in the domain of
> > > workflow engine and subsystems.
> > >
> > > The use cases for transactions in workflows is to enable consistency
> > > during workflow executions.
> > >
> > > * Constraints *
> > >
> > > The constraints for this are related to different types of transaction
> > > problems:
> > >
> > > Workflow transaction execution should be in one single transaction
> > > (until idle elements are reached or there are no more elements to
> > > process)
> > >
> > > Process state should be consistent in storage in one single
> > > transaction. In the case of database multiple tables should be written
> > > in an atomic transaction
> > >
> > > Reactive code should be removed as it does not behave properly with
> > > transactions.
> > >
> > > Transactions Policy among workflow runtime and subsystems should be
> > > consistent in terms of configuration (no subcomponent should start a
> > > transaction if there is already one on the go, but they should mandate
> > > to be in a transaction)
> > >
> > > Error handling should still produce an event that can be stored.
> > >
> > > Subsystems execution should be included during transactions
> > >
> > > Async execution will spawn its own transaction.
> > >
> > > * Architecture *
> > >
> > > The architecture of the solution impacts some areas:
> > >
> > > Components with reactive that are involved in transaction refactor. So
> > > far, the only subsystem using reactive code job service.
> > >
> > > Process Code generation should change in order to reflect the
> > > transactions of the workflow engine
> > >
> > > Error handling should be modified in a way the error is captured
> > > outside the transaction and handled in a different one to avoid event
> > > loss.
> > >
> > > Exchange information among runtime and subsystems should be in a way
> > > that those elements are involved in a transaction or they can be
> > > rolled back. At the moment the communication is being done with a rest
> > > call that is not part of the transaction and cannot be rolled back.
> > >
> > > Events produced within the transaction should be part of the
> > > transaction as well to avoid phantom events (events producing during
> > > workflow execution that are sent at the end of the unit of work)
> > >
> > > * Risk Assessment *
> > >
> > > The risks identified for this work are the following:
> > >
> > > Error handling can be problematic depending where we set the
> > > boundaries of the transaction. There are two different approaches:
> > >
> > > Boilerplate code for each task to start / commit / rollback the
> > > transaction and deail with error in the rest call tier itself
> > >
> > > Use the runtime environment to install error handling for doing the
> > > operation.
> > >
> > > Exchange information among systems in a non-transactional way. There
> > > are a couple of approaches
> > >
> > > Install every time a transaction sync listener whenever the rest call
> > > is made against the subsystem and doing a compensation when it fails
> > >
> > > Wrap the rest call in a XAResource that can be enlisted in the
> transaction.
> > >
> > > The use of Kafka clients for stream that does not belong to the
> > > transactions
> > >
> > > Wrap with XAResource (Kafka client support transactions, but does not
> > > offer XAresource)
> > >
> > > Install a transaction sync for each transaction.
> > >
> > > Performance impact with transactions.
> > >
> > > Different transaction methods in quarkus and spring boot
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
>
>
>
> --
> Saludos, Enrique González Martínez :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>

Re: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

[Enrique Gonzalez Martinez <el...@gmail.com>]

Hi Kris,

STP is a very rare case even for SWF as it depends heavily on streams.
if you don't have data sources listed in a transaction (there won't be
any overhead -empty tx-). But we can try to remove it through a flag
if the effort is not very big.

El lun, 19 ago 2024 a las 14:54, Kris Verlaenen
(<kr...@gmail.com>) escribió:
>
> Enrique,
>
> I think we are saying the same thing: if you have multiple writes and you
> want to keep strong consistency, either to one data source or to different
> data sources, you would use a transaction for this.
> If you write to one datasource, you could potentially use a local
> transaction (assuming the data source supports it) but if you have multiple
> data sources (and this for example includes sending messages) you would use
> a distributed transaction across datasources.  I have no concerns to
> optionally allow the engine to automatically start / commit transactions.
>
> My questions were mostly around use cases that might not require this,
> let's make sure we keep this optional so that we don't introduce overhead
> for use cases that might not require it (straight through processes,
> workflows without persistence, use cases where we are only targeting
> eventual consistency, etc.)***.
>
> Thx,
> Kris
>
> *** Note that the behavior might be quite different depending on your
> runtime architecture, and we might have to revisit and/or improve the
> current code base as well to better support these use cases, often things
> are not (yet) completely implemented.
>
>
> On Wed, Aug 7, 2024 at 7:04 PM Enrique Gonzalez Martinez <
> elguardian@gmail.com> wrote:
>
> > Inline answers
> >
> > El mié, 7 ago 2024 a las 18:35, Kris Verlaenen
> > (<kr...@gmail.com>) escribió:
> > >
> > > I share the concern with Francisco that we should be careful that we
> > don't
> > > introduce a solution that would require a distributed transaction to
> > > guarantee consistency, there are other approaches that might be
> > sufficient
> > > or that deliver eventual consistency that I think we should allow.
> > >
> >
> > I have never talked about distributed transactions. (if you understand
> > them we need to export transactions from the runtime to the data index
> > during execution in a distributed deployment).
> >
> > Transaction in this context means an operation execution within the
> > deployment.
> > We need transactions as several writes to the database are performed
> > during the same workflow execution. There is no other way to guarantee
> > consistency than using transactions.
> > XA (2 phase commit transactions) within the same deployment is
> > regarding some parts of the system that might write to different
> > databases. For instance runtime + data index or runtime + data audit.
> > Therefore the 2 phases commit transactions.
> >
> > > I have a few questions:
> > >  * Could you clarify what you mean with subsystems?  Because depending on
> > > your architecture I guess this could be different (for example you could
> > > run a job service embedded or as a separate service).
> >
> > Subsystems are all those services required or optional that add
> > functionality to the engine. jobs, data index, data audit, user tasks.
> >
> > > One could argue that
> > > the work of another system does not have to be done as part of the same
> > > transaction if the communication with that other system is done in a
> > > guaranteed way?  Or do we consider those not a subsystem in that case?
> >
> > The transaction is not being exported or imported from one deployment
> > to another (never talked about that). The only thing we want to
> > guarantee is that an operation within the same deployment is
> > consistent. If that requirement is met all systems will be eventually
> > consistent.
> > e.g
> >
> > Runtime executes an operation and sends events to kafka. This is a
> > transaction within the same deployment and it is consistent in
> > runtime.
> > Data index consumes the event from kafka to the storage. This is
> > another transaction within data index deployment.
> >
> > There are two different transactions. They are not the same
> > transaction but within the deployment they are consistent. and among
> > systems they will be eventually consistent as data indexes will end up
> > consuming the event.
> >
> >
> > >  * For some external services it might not be required to be part of a
> > > transaction?  For example if you're just querying some information it
> > might
> > > be totally acceptable to do this REST invocation directly and outside a
> > > transaction.
> >
> > Which system are you referring to ? For now the only invocation we
> > have within the engine is job service, so Rest cannot be outside the
> > transaction as the engine requires information exchange (we send the
> > data to create the timer and we get the job id).
> > If you are talking about service tasks (WIH) the author will have to
> > decide if it is querying or just need to create a compensation
> > mechanism.
> >
> > > Similarly, it might be fine to send out events directly,
> > > there might be other ways to compensate or ignore events later if
> > necessary.
> >
> > If you try to compensate for events in a bpmn you will tie the design
> > of the workflow to the environments. So there won't be any point in
> > the abstraction itself of the process.
> > Phantom events or Duplication events are off the table in bpmn as it
> > can impact the workflow execution. Serverless workflow might be more
> > tolerant in those abstractions but I guess that if a workflow receives
> > a phantom signal or event and executes it, I can make a guess it won't
> > be any good.
> >
> > >  * It's unclear to me how this interacts with the unit of work.  The idea
> > > of the unit of work is to collect all the changes, and then apply them
> > all
> > > at once towards the end.
> >
> > it does not matter how the unit of work does things. The unit of work
> > is not everything that happens in an execution (e.g correlation
> > service, messaging, jobs, index, audit....).
> > The interaction is about operations invoked against the engine.
> >
> > > This way you could have different implementations
> > > of the unit of work.  Is transactions a specific implementation of the
> > unit
> > > of work where you start/commit a transaction when the unit of work is
> > > started/ended?  And another alternative would be we write everything to a
> > > single data source, and use the outbox pattern or similar for further
> > > processing?
> >
> > That won't do per unit of work impl limitation. (see my previous comment).
> > Even if you have a single data source you write several times in
> > several tables, so you need transactions to keep consistency.
> >
> > >
> > > Thx,
> > > Kris
> > >
> > >
> > > On Fri, Aug 2, 2024 at 8:39 AM Enrique Gonzalez Martinez <
> > > egonzalez@apache.org> wrote:
> > >
> > > > * Transactions*
> > > > This document describes how to support transactions in the domain of
> > > > workflow engine and subsystems.
> > > >
> > > > The use cases for transactions in workflows is to enable consistency
> > > > during workflow executions.
> > > >
> > > > * Constraints *
> > > >
> > > > The constraints for this are related to different types of transaction
> > > > problems:
> > > >
> > > > Workflow transaction execution should be in one single transaction
> > > > (until idle elements are reached or there are no more elements to
> > > > process)
> > > >
> > > > Process state should be consistent in storage in one single
> > > > transaction. In the case of database multiple tables should be written
> > > > in an atomic transaction
> > > >
> > > > Reactive code should be removed as it does not behave properly with
> > > > transactions.
> > > >
> > > > Transactions Policy among workflow runtime and subsystems should be
> > > > consistent in terms of configuration (no subcomponent should start a
> > > > transaction if there is already one on the go, but they should mandate
> > > > to be in a transaction)
> > > >
> > > > Error handling should still produce an event that can be stored.
> > > >
> > > > Subsystems execution should be included during transactions
> > > >
> > > > Async execution will spawn its own transaction.
> > > >
> > > > * Architecture *
> > > >
> > > > The architecture of the solution impacts some areas:
> > > >
> > > > Components with reactive that are involved in transaction refactor. So
> > > > far, the only subsystem using reactive code job service.
> > > >
> > > > Process Code generation should change in order to reflect the
> > > > transactions of the workflow engine
> > > >
> > > > Error handling should be modified in a way the error is captured
> > > > outside the transaction and handled in a different one to avoid event
> > > > loss.
> > > >
> > > > Exchange information among runtime and subsystems should be in a way
> > > > that those elements are involved in a transaction or they can be
> > > > rolled back. At the moment the communication is being done with a rest
> > > > call that is not part of the transaction and cannot be rolled back.
> > > >
> > > > Events produced within the transaction should be part of the
> > > > transaction as well to avoid phantom events (events producing during
> > > > workflow execution that are sent at the end of the unit of work)
> > > >
> > > > * Risk Assessment *
> > > >
> > > > The risks identified for this work are the following:
> > > >
> > > > Error handling can be problematic depending where we set the
> > > > boundaries of the transaction. There are two different approaches:
> > > >
> > > > Boilerplate code for each task to start / commit / rollback the
> > > > transaction and deail with error in the rest call tier itself
> > > >
> > > > Use the runtime environment to install error handling for doing the
> > > > operation.
> > > >
> > > > Exchange information among systems in a non-transactional way. There
> > > > are a couple of approaches
> > > >
> > > > Install every time a transaction sync listener whenever the rest call
> > > > is made against the subsystem and doing a compensation when it fails
> > > >
> > > > Wrap the rest call in a XAResource that can be enlisted in the
> > transaction.
> > > >
> > > > The use of Kafka clients for stream that does not belong to the
> > > > transactions
> > > >
> > > > Wrap with XAResource (Kafka client support transactions, but does not
> > > > offer XAresource)
> > > >
> > > > Install a transaction sync for each transaction.
> > > >
> > > > Performance impact with transactions.
> > > >
> > > > Different transaction methods in quarkus and spring boot
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >
> >
> > --
> > Saludos, Enrique González Martínez :)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
> >
> >



-- 
Saludos, Enrique González Martínez :)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org

Re: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

[Kris Verlaenen <kr...@gmail.com>]

Enrique,

I think we are saying the same thing: if you have multiple writes and you
want to keep strong consistency, either to one data source or to different
data sources, you would use a transaction for this.
If you write to one datasource, you could potentially use a local
transaction (assuming the data source supports it) but if you have multiple
data sources (and this for example includes sending messages) you would use
a distributed transaction across datasources.  I have no concerns to
optionally allow the engine to automatically start / commit transactions.

My questions were mostly around use cases that might not require this,
let's make sure we keep this optional so that we don't introduce overhead
for use cases that might not require it (straight through processes,
workflows without persistence, use cases where we are only targeting
eventual consistency, etc.)***.

Thx,
Kris

*** Note that the behavior might be quite different depending on your
runtime architecture, and we might have to revisit and/or improve the
current code base as well to better support these use cases, often things
are not (yet) completely implemented.


On Wed, Aug 7, 2024 at 7:04 PM Enrique Gonzalez Martinez <
elguardian@gmail.com> wrote:

> Inline answers
>
> El mié, 7 ago 2024 a las 18:35, Kris Verlaenen
> (<kr...@gmail.com>) escribió:
> >
> > I share the concern with Francisco that we should be careful that we
> don't
> > introduce a solution that would require a distributed transaction to
> > guarantee consistency, there are other approaches that might be
> sufficient
> > or that deliver eventual consistency that I think we should allow.
> >
>
> I have never talked about distributed transactions. (if you understand
> them we need to export transactions from the runtime to the data index
> during execution in a distributed deployment).
>
> Transaction in this context means an operation execution within the
> deployment.
> We need transactions as several writes to the database are performed
> during the same workflow execution. There is no other way to guarantee
> consistency than using transactions.
> XA (2 phase commit transactions) within the same deployment is
> regarding some parts of the system that might write to different
> databases. For instance runtime + data index or runtime + data audit.
> Therefore the 2 phases commit transactions.
>
> > I have a few questions:
> >  * Could you clarify what you mean with subsystems?  Because depending on
> > your architecture I guess this could be different (for example you could
> > run a job service embedded or as a separate service).
>
> Subsystems are all those services required or optional that add
> functionality to the engine. jobs, data index, data audit, user tasks.
>
> > One could argue that
> > the work of another system does not have to be done as part of the same
> > transaction if the communication with that other system is done in a
> > guaranteed way?  Or do we consider those not a subsystem in that case?
>
> The transaction is not being exported or imported from one deployment
> to another (never talked about that). The only thing we want to
> guarantee is that an operation within the same deployment is
> consistent. If that requirement is met all systems will be eventually
> consistent.
> e.g
>
> Runtime executes an operation and sends events to kafka. This is a
> transaction within the same deployment and it is consistent in
> runtime.
> Data index consumes the event from kafka to the storage. This is
> another transaction within data index deployment.
>
> There are two different transactions. They are not the same
> transaction but within the deployment they are consistent. and among
> systems they will be eventually consistent as data indexes will end up
> consuming the event.
>
>
> >  * For some external services it might not be required to be part of a
> > transaction?  For example if you're just querying some information it
> might
> > be totally acceptable to do this REST invocation directly and outside a
> > transaction.
>
> Which system are you referring to ? For now the only invocation we
> have within the engine is job service, so Rest cannot be outside the
> transaction as the engine requires information exchange (we send the
> data to create the timer and we get the job id).
> If you are talking about service tasks (WIH) the author will have to
> decide if it is querying or just need to create a compensation
> mechanism.
>
> > Similarly, it might be fine to send out events directly,
> > there might be other ways to compensate or ignore events later if
> necessary.
>
> If you try to compensate for events in a bpmn you will tie the design
> of the workflow to the environments. So there won't be any point in
> the abstraction itself of the process.
> Phantom events or Duplication events are off the table in bpmn as it
> can impact the workflow execution. Serverless workflow might be more
> tolerant in those abstractions but I guess that if a workflow receives
> a phantom signal or event and executes it, I can make a guess it won't
> be any good.
>
> >  * It's unclear to me how this interacts with the unit of work.  The idea
> > of the unit of work is to collect all the changes, and then apply them
> all
> > at once towards the end.
>
> it does not matter how the unit of work does things. The unit of work
> is not everything that happens in an execution (e.g correlation
> service, messaging, jobs, index, audit....).
> The interaction is about operations invoked against the engine.
>
> > This way you could have different implementations
> > of the unit of work.  Is transactions a specific implementation of the
> unit
> > of work where you start/commit a transaction when the unit of work is
> > started/ended?  And another alternative would be we write everything to a
> > single data source, and use the outbox pattern or similar for further
> > processing?
>
> That won't do per unit of work impl limitation. (see my previous comment).
> Even if you have a single data source you write several times in
> several tables, so you need transactions to keep consistency.
>
> >
> > Thx,
> > Kris
> >
> >
> > On Fri, Aug 2, 2024 at 8:39 AM Enrique Gonzalez Martinez <
> > egonzalez@apache.org> wrote:
> >
> > > * Transactions*
> > > This document describes how to support transactions in the domain of
> > > workflow engine and subsystems.
> > >
> > > The use cases for transactions in workflows is to enable consistency
> > > during workflow executions.
> > >
> > > * Constraints *
> > >
> > > The constraints for this are related to different types of transaction
> > > problems:
> > >
> > > Workflow transaction execution should be in one single transaction
> > > (until idle elements are reached or there are no more elements to
> > > process)
> > >
> > > Process state should be consistent in storage in one single
> > > transaction. In the case of database multiple tables should be written
> > > in an atomic transaction
> > >
> > > Reactive code should be removed as it does not behave properly with
> > > transactions.
> > >
> > > Transactions Policy among workflow runtime and subsystems should be
> > > consistent in terms of configuration (no subcomponent should start a
> > > transaction if there is already one on the go, but they should mandate
> > > to be in a transaction)
> > >
> > > Error handling should still produce an event that can be stored.
> > >
> > > Subsystems execution should be included during transactions
> > >
> > > Async execution will spawn its own transaction.
> > >
> > > * Architecture *
> > >
> > > The architecture of the solution impacts some areas:
> > >
> > > Components with reactive that are involved in transaction refactor. So
> > > far, the only subsystem using reactive code job service.
> > >
> > > Process Code generation should change in order to reflect the
> > > transactions of the workflow engine
> > >
> > > Error handling should be modified in a way the error is captured
> > > outside the transaction and handled in a different one to avoid event
> > > loss.
> > >
> > > Exchange information among runtime and subsystems should be in a way
> > > that those elements are involved in a transaction or they can be
> > > rolled back. At the moment the communication is being done with a rest
> > > call that is not part of the transaction and cannot be rolled back.
> > >
> > > Events produced within the transaction should be part of the
> > > transaction as well to avoid phantom events (events producing during
> > > workflow execution that are sent at the end of the unit of work)
> > >
> > > * Risk Assessment *
> > >
> > > The risks identified for this work are the following:
> > >
> > > Error handling can be problematic depending where we set the
> > > boundaries of the transaction. There are two different approaches:
> > >
> > > Boilerplate code for each task to start / commit / rollback the
> > > transaction and deail with error in the rest call tier itself
> > >
> > > Use the runtime environment to install error handling for doing the
> > > operation.
> > >
> > > Exchange information among systems in a non-transactional way. There
> > > are a couple of approaches
> > >
> > > Install every time a transaction sync listener whenever the rest call
> > > is made against the subsystem and doing a compensation when it fails
> > >
> > > Wrap the rest call in a XAResource that can be enlisted in the
> transaction.
> > >
> > > The use of Kafka clients for stream that does not belong to the
> > > transactions
> > >
> > > Wrap with XAResource (Kafka client support transactions, but does not
> > > offer XAresource)
> > >
> > > Install a transaction sync for each transaction.
> > >
> > > Performance impact with transactions.
> > >
> > > Different transaction methods in quarkus and spring boot
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
>
>
>
> --
> Saludos, Enrique González Martínez :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>

Re: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

[Enrique Gonzalez Martinez <el...@gmail.com>]

Inline answers

El mié, 7 ago 2024 a las 18:35, Kris Verlaenen
(<kr...@gmail.com>) escribió:
>
> I share the concern with Francisco that we should be careful that we don't
> introduce a solution that would require a distributed transaction to
> guarantee consistency, there are other approaches that might be sufficient
> or that deliver eventual consistency that I think we should allow.
>

I have never talked about distributed transactions. (if you understand
them we need to export transactions from the runtime to the data index
during execution in a distributed deployment).

Transaction in this context means an operation execution within the deployment.
We need transactions as several writes to the database are performed
during the same workflow execution. There is no other way to guarantee
consistency than using transactions.
XA (2 phase commit transactions) within the same deployment is
regarding some parts of the system that might write to different
databases. For instance runtime + data index or runtime + data audit.
Therefore the 2 phases commit transactions.

> I have a few questions:
>  * Could you clarify what you mean with subsystems?  Because depending on
> your architecture I guess this could be different (for example you could
> run a job service embedded or as a separate service).

Subsystems are all those services required or optional that add
functionality to the engine. jobs, data index, data audit, user tasks.

> One could argue that
> the work of another system does not have to be done as part of the same
> transaction if the communication with that other system is done in a
> guaranteed way?  Or do we consider those not a subsystem in that case?

The transaction is not being exported or imported from one deployment
to another (never talked about that). The only thing we want to
guarantee is that an operation within the same deployment is
consistent. If that requirement is met all systems will be eventually
consistent.
e.g

Runtime executes an operation and sends events to kafka. This is a
transaction within the same deployment and it is consistent in
runtime.
Data index consumes the event from kafka to the storage. This is
another transaction within data index deployment.

There are two different transactions. They are not the same
transaction but within the deployment they are consistent. and among
systems they will be eventually consistent as data indexes will end up
consuming the event.


>  * For some external services it might not be required to be part of a
> transaction?  For example if you're just querying some information it might
> be totally acceptable to do this REST invocation directly and outside a
> transaction.

Which system are you referring to ? For now the only invocation we
have within the engine is job service, so Rest cannot be outside the
transaction as the engine requires information exchange (we send the
data to create the timer and we get the job id).
If you are talking about service tasks (WIH) the author will have to
decide if it is querying or just need to create a compensation
mechanism.

> Similarly, it might be fine to send out events directly,
> there might be other ways to compensate or ignore events later if necessary.

If you try to compensate for events in a bpmn you will tie the design
of the workflow to the environments. So there won't be any point in
the abstraction itself of the process.
Phantom events or Duplication events are off the table in bpmn as it
can impact the workflow execution. Serverless workflow might be more
tolerant in those abstractions but I guess that if a workflow receives
a phantom signal or event and executes it, I can make a guess it won't
be any good.

>  * It's unclear to me how this interacts with the unit of work.  The idea
> of the unit of work is to collect all the changes, and then apply them all
> at once towards the end.

it does not matter how the unit of work does things. The unit of work
is not everything that happens in an execution (e.g correlation
service, messaging, jobs, index, audit....).
The interaction is about operations invoked against the engine.

> This way you could have different implementations
> of the unit of work.  Is transactions a specific implementation of the unit
> of work where you start/commit a transaction when the unit of work is
> started/ended?  And another alternative would be we write everything to a
> single data source, and use the outbox pattern or similar for further
> processing?

That won't do per unit of work impl limitation. (see my previous comment).
Even if you have a single data source you write several times in
several tables, so you need transactions to keep consistency.

>
> Thx,
> Kris
>
>
> On Fri, Aug 2, 2024 at 8:39 AM Enrique Gonzalez Martinez <
> egonzalez@apache.org> wrote:
>
> > * Transactions*
> > This document describes how to support transactions in the domain of
> > workflow engine and subsystems.
> >
> > The use cases for transactions in workflows is to enable consistency
> > during workflow executions.
> >
> > * Constraints *
> >
> > The constraints for this are related to different types of transaction
> > problems:
> >
> > Workflow transaction execution should be in one single transaction
> > (until idle elements are reached or there are no more elements to
> > process)
> >
> > Process state should be consistent in storage in one single
> > transaction. In the case of database multiple tables should be written
> > in an atomic transaction
> >
> > Reactive code should be removed as it does not behave properly with
> > transactions.
> >
> > Transactions Policy among workflow runtime and subsystems should be
> > consistent in terms of configuration (no subcomponent should start a
> > transaction if there is already one on the go, but they should mandate
> > to be in a transaction)
> >
> > Error handling should still produce an event that can be stored.
> >
> > Subsystems execution should be included during transactions
> >
> > Async execution will spawn its own transaction.
> >
> > * Architecture *
> >
> > The architecture of the solution impacts some areas:
> >
> > Components with reactive that are involved in transaction refactor. So
> > far, the only subsystem using reactive code job service.
> >
> > Process Code generation should change in order to reflect the
> > transactions of the workflow engine
> >
> > Error handling should be modified in a way the error is captured
> > outside the transaction and handled in a different one to avoid event
> > loss.
> >
> > Exchange information among runtime and subsystems should be in a way
> > that those elements are involved in a transaction or they can be
> > rolled back. At the moment the communication is being done with a rest
> > call that is not part of the transaction and cannot be rolled back.
> >
> > Events produced within the transaction should be part of the
> > transaction as well to avoid phantom events (events producing during
> > workflow execution that are sent at the end of the unit of work)
> >
> > * Risk Assessment *
> >
> > The risks identified for this work are the following:
> >
> > Error handling can be problematic depending where we set the
> > boundaries of the transaction. There are two different approaches:
> >
> > Boilerplate code for each task to start / commit / rollback the
> > transaction and deail with error in the rest call tier itself
> >
> > Use the runtime environment to install error handling for doing the
> > operation.
> >
> > Exchange information among systems in a non-transactional way. There
> > are a couple of approaches
> >
> > Install every time a transaction sync listener whenever the rest call
> > is made against the subsystem and doing a compensation when it fails
> >
> > Wrap the rest call in a XAResource that can be enlisted in the transaction.
> >
> > The use of Kafka clients for stream that does not belong to the
> > transactions
> >
> > Wrap with XAResource (Kafka client support transactions, but does not
> > offer XAresource)
> >
> > Install a transaction sync for each transaction.
> >
> > Performance impact with transactions.
> >
> > Different transaction methods in quarkus and spring boot
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org



-- 
Saludos, Enrique González Martínez :)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org

Re: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

[Kris Verlaenen <kr...@gmail.com>]

I share the concern with Francisco that we should be careful that we don't
introduce a solution that would require a distributed transaction to
guarantee consistency, there are other approaches that might be sufficient
or that deliver eventual consistency that I think we should allow.

I have a few questions:
 * Could you clarify what you mean with subsystems?  Because depending on
your architecture I guess this could be different (for example you could
run a job service embedded or as a separate service).  One could argue that
the work of another system does not have to be done as part of the same
transaction if the communication with that other system is done in a
guaranteed way?  Or do we consider those not a subsystem in that case?
 * For some external services it might not be required to be part of a
transaction?  For example if you're just querying some information it might
be totally acceptable to do this REST invocation directly and outside a
transaction.  Similarly, it might be fine to send out events directly,
there might be other ways to compensate or ignore events later if necessary.
 * It's unclear to me how this interacts with the unit of work.  The idea
of the unit of work is to collect all the changes, and then apply them all
at once towards the end.  This way you could have different implementations
of the unit of work.  Is transactions a specific implementation of the unit
of work where you start/commit a transaction when the unit of work is
started/ended?  And another alternative would be we write everything to a
single data source, and use the outbox pattern or similar for further
processing?

Thx,
Kris


On Fri, Aug 2, 2024 at 8:39 AM Enrique Gonzalez Martinez <
egonzalez@apache.org> wrote:

> * Transactions*
> This document describes how to support transactions in the domain of
> workflow engine and subsystems.
>
> The use cases for transactions in workflows is to enable consistency
> during workflow executions.
>
> * Constraints *
>
> The constraints for this are related to different types of transaction
> problems:
>
> Workflow transaction execution should be in one single transaction
> (until idle elements are reached or there are no more elements to
> process)
>
> Process state should be consistent in storage in one single
> transaction. In the case of database multiple tables should be written
> in an atomic transaction
>
> Reactive code should be removed as it does not behave properly with
> transactions.
>
> Transactions Policy among workflow runtime and subsystems should be
> consistent in terms of configuration (no subcomponent should start a
> transaction if there is already one on the go, but they should mandate
> to be in a transaction)
>
> Error handling should still produce an event that can be stored.
>
> Subsystems execution should be included during transactions
>
> Async execution will spawn its own transaction.
>
> * Architecture *
>
> The architecture of the solution impacts some areas:
>
> Components with reactive that are involved in transaction refactor. So
> far, the only subsystem using reactive code job service.
>
> Process Code generation should change in order to reflect the
> transactions of the workflow engine
>
> Error handling should be modified in a way the error is captured
> outside the transaction and handled in a different one to avoid event
> loss.
>
> Exchange information among runtime and subsystems should be in a way
> that those elements are involved in a transaction or they can be
> rolled back. At the moment the communication is being done with a rest
> call that is not part of the transaction and cannot be rolled back.
>
> Events produced within the transaction should be part of the
> transaction as well to avoid phantom events (events producing during
> workflow execution that are sent at the end of the unit of work)
>
> * Risk Assessment *
>
> The risks identified for this work are the following:
>
> Error handling can be problematic depending where we set the
> boundaries of the transaction. There are two different approaches:
>
> Boilerplate code for each task to start / commit / rollback the
> transaction and deail with error in the rest call tier itself
>
> Use the runtime environment to install error handling for doing the
> operation.
>
> Exchange information among systems in a non-transactional way. There
> are a couple of approaches
>
> Install every time a transaction sync listener whenever the rest call
> is made against the subsystem and doing a compensation when it fails
>
> Wrap the rest call in a XAResource that can be enlisted in the transaction.
>
> The use of Kafka clients for stream that does not belong to the
> transactions
>
> Wrap with XAResource (Kafka client support transactions, but does not
> offer XAresource)
>
> Install a transaction sync for each transaction.
>
> Performance impact with transactions.
>
> Different transaction methods in quarkus and spring boot
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org

Re: [PROPOSAL][WORKFLOW] Transaction in workflow runtime

[Yeser Amer <ya...@apache.org>]

+ 1

On 2024/08/02 06:38:32 Enrique Gonzalez Martinez wrote:
> * Transactions*
> This document describes how to support transactions in the domain of
> workflow engine and subsystems.
> 
> The use cases for transactions in workflows is to enable consistency
> during workflow executions.
> 
> * Constraints *
> 
> The constraints for this are related to different types of transaction problems:
> 
> Workflow transaction execution should be in one single transaction
> (until idle elements are reached or there are no more elements to
> process)
> 
> Process state should be consistent in storage in one single
> transaction. In the case of database multiple tables should be written
> in an atomic transaction
> 
> Reactive code should be removed as it does not behave properly with
> transactions.
> 
> Transactions Policy among workflow runtime and subsystems should be
> consistent in terms of configuration (no subcomponent should start a
> transaction if there is already one on the go, but they should mandate
> to be in a transaction)
> 
> Error handling should still produce an event that can be stored.
> 
> Subsystems execution should be included during transactions
> 
> Async execution will spawn its own transaction.
> 
> * Architecture *
> 
> The architecture of the solution impacts some areas:
> 
> Components with reactive that are involved in transaction refactor. So
> far, the only subsystem using reactive code job service.
> 
> Process Code generation should change in order to reflect the
> transactions of the workflow engine
> 
> Error handling should be modified in a way the error is captured
> outside the transaction and handled in a different one to avoid event
> loss.
> 
> Exchange information among runtime and subsystems should be in a way
> that those elements are involved in a transaction or they can be
> rolled back. At the moment the communication is being done with a rest
> call that is not part of the transaction and cannot be rolled back.
> 
> Events produced within the transaction should be part of the
> transaction as well to avoid phantom events (events producing during
> workflow execution that are sent at the end of the unit of work)
> 
> * Risk Assessment *
> 
> The risks identified for this work are the following:
> 
> Error handling can be problematic depending where we set the
> boundaries of the transaction. There are two different approaches:
> 
> Boilerplate code for each task to start / commit / rollback the
> transaction and deail with error in the rest call tier itself
> 
> Use the runtime environment to install error handling for doing the operation.
> 
> Exchange information among systems in a non-transactional way. There
> are a couple of approaches
> 
> Install every time a transaction sync listener whenever the rest call
> is made against the subsystem and doing a compensation when it fails
> 
> Wrap the rest call in a XAResource that can be enlisted in the transaction.
> 
> The use of Kafka clients for stream that does not belong to the transactions
> 
> Wrap with XAResource (Kafka client support transactions, but does not
> offer XAresource)
> 
> Install a transaction sync for each transaction.
> 
> Performance impact with transactions.
> 
> Different transaction methods in quarkus and spring boot
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org