How to use @Retry on a @Transactional method?

[HerrDerb]

I want to use @Retry on a @Transactional method in Quarkus. With @Retry I want to retry a db write/update action if the transaction has failed.

@Transactional
@Retry(retryOn = {StaleStateException.class})
void myMethod(){
  ...
}

@Retry has a priority of 4000 whereas @Transaction has a priority of 100.
This means the fault tolerance interceptor never gets the change to handle a exception thrown by the transactional interceptor.

No I've got two options on how tho handle this.

Option 1

nested methods (👎lots of bulk)

@Retry(retryOn = {StaleStateException.class})
void myMethod(){
  myTransactionalMethod();
}

@Transactional
void myTransactionalMethod(){
  ...
}

Option 2

setting default priority of fault tolerance interceptor by config property (a bit unsure about the global effects)
mp.fault.tolerance.interceptor.priority=100

I do tend to Option 2. Do I need to worry, that this breaks any intended behaviour of the fault tolerance framework?

[Ladicek]

You're not the first to stumble upon this, see for example #605. I'll repeat my comment from there: I haven't been involved in MicroProfile Fault Tolerance since the beginning, but my opinion is that MicroProfile Fault Tolerance was designed chiefly for guarding network interactions and when you try to apply it elsewhere, all kinds of cracks start to appear. I think this is one of those.

I don't think changing the priority of the FT interceptor would affect the fault tolerance behavior itself -- but it may affect other parts of the system, which is an unbounded number of combinations. My favorite example is JPA with Hibernate. Whenever a Hibernate method throws an exception, the Hibernate session becomes unusable and must be dropped. Therefore, blindly retrying can cause more troubles than it solves.

[Azquelt]

Yep, fault tolerance is implemented using an interceptor and so the way it interacts with other interceptors depends on the priority. This was the reason the mp.fault.tolerance.interceptor.priority config property was added, using it to ensure Fault Tolerance occurs around the @Transactional interceptor (rather that within it) is what it was designed for (though I would set it lower than 100 to ensure that it happens first).

This will also change the order that fault tolerance occurs in relation to any other interceptors that are active in your application.

We had a bit of a debate over what the correct default priority was, there's unfortunately no right answer here, different users may want other interceptors to fire around or within the fault tolerance retry loop.