Transaction, uow

💻 Core Engineering
#1

Hi, it is good to know that 2022.9 we would be able to create db transactions with stand-alone tables. I will use that.

Please, I want to ask if inside 2022.3 the workflows or automation scripts, internally use a uow with db transactions? If yes, how would be the behaviour with 2022.9 new transactions functionality, the default uow is disable to work with customs transactions?

#2

I’m not sure I understand what you’re asking but most service operations (creating records, updating modules, deleting templates, …) run their operation(s) in a DB transaction.

The transaction isn’t exposed in a way where you could add multiple uow (units of work) into that one transaction so a create user workflow step is its own transaction independent of the next create record step (in case the create record fails you can’t rollback the user creation).

In 2022.9 we’d like to provide a way for you to open a transaction, do the work, and then commit/rollback it which would allow you to run entire workflows in a single transaction if you want.
This isn’t as trivial as we hoped so we’ll probably progressively improve on this.

I hope this answers it; if not please elaborate further on it

1 Like
#3

Yes it is a helpful answer.
So right now in 2022.3 transactions are not managed by workflows. I have many ideas that may help in design:

  • A workflow could be optionally wrapped by a transaction. So a developer can choose (maybe with a checkbox in workflow configuration). If wrapped transaction is enable, the blocks (steps) for open/commit/rollback a transction should not be available.
  • It would be helpful that inside a workflow we call another workflow (or the same, recursive calls) to allow logic reuse (DRY principle). If this is possible, the wrapper transaction should cover all workflows (the current and subworkflows).
  • Corteza has the great stale-data control (I think it is optimistic concurrency). Before a commit is made the stale-date control should be done automatically.
  • A more advanced approach would be to have a kind of changeTracker (like efcore), so when the workflow ends without exceptions, the transaction is open and commit (with stale-date check) sequentially so the transaction does not remain open while the workflow is making bussiness operations (or rest api calls to external systems), Martin Fowler explain better than I, uow Martin Fowler

Thanks for this great low-code platform.

1 Like