Hello everyone,
I am studying for Web Developer Specialist and i have a doubt regarding the abort transactions when there is an exception.
In the documentation it states the following:
"If an exception occurs and it's left uncaught, the transaction is rolled back. This means that changes made to the database within the transaction are all reverted, this way ensuring that your data remains consistent.
If an exception occurs and there's an Exception Handler that handles that exception, you can configure what happens to the currently open transaction in the Exception Handler's Abort Transaction property. Check Aborting database transactions for more information."
So basically when you are executing a server action and there is a exception and you don´t have a exception handler defined in the flow of the action, the transaction is rolled back.
Then i thought about some more complex cases that are not stated in the documentation (one in the sample exam of the web specialist)..
1 - server action with a REST API node in the flow followed by a server action (main server action has exception handler with abort transaction to yes) - error in the second server action - sample test says the correct answer is api data is not rolled back and server action data is rolled back)
2 - Server action consisted of several server action without any exception handler (exception occurs in the second action, according to the first statement it´s safe to assume all data is rolled back if there is no exception handler)
3 - Server action consisted of 3 server action (main server action has exception handler with abort transaction to yes) - exception ocurrs in the second action, i assume all data is rolled back
4 - Having 3 server actions inside a server action (the second action has exception handler with abort transaction to yes, the others 2 don´t have exception handler) - exception occurs in the second action, i this case i think data from first action is committed and the second is rolled back, the third is not even executed so it doesn´t matter.
What data is committed and what data is rolled back in these cases?
This exam can be very tricky because they will assume you have the experience and has questions that are not stated in the documentation like this kind :/
Thanks
Your assumptions are correct for 1, 2 & 3.
In the case of 4th question (where there is an exception and exception handler in second action )
You may create a simple project with one entity + 4 server actions and try it out.
Hi,
Key in all your use cases is to understand that AbortTransaction issues a ROLLBACK statement that undoes all changes performed on the database since the beginning of the current transaction. It also ends the current transaction and starts a new one. After Abort Transaction the action flow continues!
Not mentioned, but also imported to understand that nested transactions are supported, transaction are always sequential.
for more information read:
https://success.outsystems.com/documentation/11/reference/outsystems_language/data/database_reference/handling_transactions/
Regards,
Daniel
Hi @Sérgio Pinto
If a server action or any nested server actions fail, all changes will roll back unless you include a commit in your logic or set the exception handler's "Abort Transaction" property to No.
For service actions, since they run in their own context and are outside the transaction scope of server actions, then they won't roll back automatically. You'll need to handle their exceptions and implement the rollback programmatically.
So, 1, 2 and 3 are correct. For number 4, If an exception occurs in the second server action and its exception handler has "Abort Transaction" set to Yes, the entire transaction will roll back (all server actions are in the same transaction), including any changes made by the first server action.
Kind regards,
Tami
Hello and thanks everyone for their answers!
So we can conclude that when there is an exception (of any kind) in the flow of a server action and there is no exception handler defined, the transactions are always rolled back unless one of the nodes of the flow, for example is a REST API, which contacts an external system, is a different transaction right and can´t be rolled back.
If it´s on the same "system" it´s the same transaction, even if a server action have several transactions inside.
The only difference is if you commit the transaction programmatically or have an exception handler specifically with the abort transaction to no.
There are only 2 questions regarding Exception/Transaction Handling in the exam but it can make the difference between a pass and a fail.
What i am not 100% sure is if the flow continues it´s execution when there is an exception (not a raise exception node), for example, in the case with a server action with 3 server actions inside, and there is a database exception in the second action (for example trying to delete a record), does the flow continue executing the rest of flow of the 2nd action, and then exists and goes to the flow of the 3rd server action anyway?
The assumption i had was that if there is an error in the flow of an action, the flow exits in most of the cases, (client side or server side).
What i am not 100% sure is if the flow continues it´s execution when there is an exception (not a raise exception node), for example, in the case with a server action with 3 server actions inside, and there is a database exception in the second action (for example trying to delete a record), does the flow continue executing the rest of flow of the 2nd action, and then exists and goes to the flow of the 3rd server action anyway? The assumption i had was that if there is an error in the flow of an action, the flow exits in most of the cases, (client side or server side).
A database exception will not be handled differently from a programatically raised exception. The flow it happens in (=the happy flow of action_2) will not continue with nodes past the point of failure.
So instead of the raise exception node being the last one, this would then be the Create node or the SQL node or whatever you are trying to do in the database.
The next thing that happens is the first exception handler it finds. So if that is an exception handler INSIDE action_2, then all logic in your main server action and action_3 will just continue executing their happy flow.
Whether your changes, inside the same transaction, before the exception are persisted or not, is determined by the abort transaction property of that exception handler.
Dorine
To make it easier to think about, just visualise that the node doing stuff on the database is a nested server action raising an exception without an exception handler.
Documentation here: Click Here and here