The cost of Transaction failures

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:

  1. we get the documents through Transaction API that we want to operate on - some we extract information out from, some we update,
  2. 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,
  3. we may also call remote third party APIs that may throw application exceptions,
  4. 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.


1 Like

Hi @zoltan.zvara
Well, in any database there is a little overhead to a transaction. There are some details to the underlying mechanics of our implementation here. Long story short, each aborted transaction attempt involves 3 writes to an Active Transaction Record (ATR) document, and 1 or more documents are staged then rolled back (e.g. 2 writes apiece). A transaction can involve multiple attempts, but in the scenarios you’re outlined there (e.g. raising application exceptions from the lambda), it’ll always be a fast-fail, e.g. one attempt.
So it’s not super high overhead, but if you’re looking to avoid wasted writes, then I would certainly recommend checking all your prerequisites before the lambda.
Update: with the caveat, where possible. You need to do reads inside the lambda, and I wouldn’t do a pre-lambda read of any documents purely in order to check preconditions and avoid wasted writes. Unless in some highly unusual situation e.g. 90% of the time the transaction will fail based on the document content.

1 Like