The cost of Transaction failures

Java SDK
1

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.

image
image725×357 30.1 KB

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.

Thanks!

1 Like
2

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