Question

Database rollback

0

I was interested in the question by Rene Smit about how to force a database-level commit to occur from within a microflow by ending the transaction prematurely. Would it be possible to force a rollback by similar means? I would like to restore the database to the state it was in just before the microflow started if for example something goes wrong with the process or the user cancels it. It would take a long time to go back and undo explicitly everything the microflow had done up to this point, but it looks as if the system does something like this for example if I terminate the business server whilst the microflow is running.

asked 2010-09-05

Martin Bucknall

2 answers

Lex van Rooy (Gmail) · Answer 1 · 2010-09-05

if you would use "standard" audit-trail functionality you would create a before image and an after image. Going back would then simply be an issue of reverting to the before image

Jasper van der Hoek · Answer 2 · 2010-09-06

It is correct that the microflow does something like your describing when an exception occures. It reverts all the changes that have been done in the microflow.
See this wiki page : https://world.mendix.com/pages/releaseview.action?pageId=3736919 (bottom of the page)

However influencing transactions and the context isn't as easy as calling only a single rollback if you want to revert all changes. This causes all of your objects to be unavailable to the application. All objects from the same type as the objects you changed in your flow can't be retrieved any more and all your retrieve actions keep waiting forever.
This bug I am describing is one you will be seeing verry often when you start working with transactions.

The most important thing is that you always start the same amount of transactions as you end or rollback.
So if you want to do a rollback you also have to do a start transaction at the begin of the flow, an rollback when you want to revert the changes and an endtransaction at the end of the flow (when executed correctly)

Another thing, you should not use to many transactions the more transactions you start how bigger the load becomes for the datebase (you might remember the postgres out of shared memory exceptions) database exceptions are usually caused by using custom transactions (or errorhandling, which creates a new transaction) the wrong way or to often.

This are only a few of the problems I have ran into and I can think of in a few minutes. There are many more bugs and strange cases you have to think of.

Transactions can be verry usefull, but can cause a lot of problems. So if you suddenly get some strange exceptions or behaviour in your application, start debugging and counting your transaction calls.