In our code that uses the Transaction API’s
run, we add application logic to that lambda that may throw errors along the way in various ways.
In general in the lambda
f: AttemptContext => R:
- we get the documents through Transaction API that we want to operate on - some we extract information out from, some we update,
- along the way we check for certain prerequisites to be present for the transaction to be committed - we use assertions and we throw application exceptions out from the lambda like a ball,
- we may also call remote third party APIs that may throw application exceptions,
- if all goes well, we commit the transaction at the end of the lambda.
AFAIK, the once
f throws an error, the Transactions API will irrecoverably fail the transaction and attempt a rollback. It would be great to know: what is the cost of this?
Step 2 and 3 usually (98% of time) throws exception while executed outside of a transaction. Could refactoring step 2 and 3 before starting the transaction improve application and CB performance? Let’s say we execute 1, 2 and 3 to check if everything is alright, then execute step 1-4 in a transaction altogether.