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

2 Likes
#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
#4

Hi @tjerman, have there been any recent developments regarding the transactions ?

1 Like
#5

Sadly no… conceptually yes, but there were some development hickups that pushed this feature down a bit.

#6

Alright, understood. You’re already doing a great job. However, could you advise me on strategies to simulate the transactions ?

1 Like
#7

Huh… I don’t think there is a straightforward way to do this… These options come to mind, but they might be as extreme as it gets (they’re all for automation scripts)…

Open your DB connection

Make a DB connection, open a transaction, construct and run queries manually, commit/rollback transaction.

Make a temporary state before flushing to the DB

All modifications that you’d store in the database (such as record updates), you’d write to some JSON, which would keep track of changes.
Once the script is done, you’d flush that JSON to the DB.

None of this is (probably) bulletproof, and it would only work for things performed in the automation script.

#8

Thank you for the guidance.

1 Like
#9

Let me know if you decide to go for any of these options.
Alternatively, if you have any experience/ideas for working with (long-lasting) transactions (across different databases), do tell

#10

I’m thinking of testing both options before deciding, or maybe revisiting my workflows to minimize the need for transactions.

1 Like
#11

Coolio, keep me updated because I’m quite curious how you’ll go around it :sweat_smile:

#12

Still exploring a few paths, but I’ll let you know how it goes.

1 Like