Using @Retry and @Transactional on the same method

[matthiaswelz]

As an application developer I need to be able to use the @Retry annotation in a JTA-enabled application which enables me to provide fault tolerance to transactional methods.

However, this is currently not possible because the specification currently states that:

The base priority of the lowest priority Fault Tolerance interceptor is Priority.PLATFORM_AFTER+10, which is 4010

while the JTA specification states that:

The Transactional interceptors must have a
priority of Interceptor.Priority.PLATFORM_BEFORE+200.

This means that the transactional interceptor will run before the fault tolerance interceptor and all retries will take place in the same transaction. This is an issue for many reasons:

1. There might be side-effects from a previous attempt attached to the transaction (especially when also using JPA / Hibernate)
2. The transaction might have timed out already or failed for another reason, so the retry is bound to fail
3. Deadlock scenarios are possible if the transaction is reused for multiple retries.

The spec should make clear what happens when combining @Retry and @Transactional. One possibility could be introducing another annotation which specifies what happens to the transaction during retries.

Also see: smallrye/smallrye-fault-tolerance#629

[Azquelt]

You can modify the priority of the Fault Tolerance interceptor by setting the mp.fault.tolerance.interceptor.priority config property if you need fault tolerance to be applied at a different point in the interceptor chain.

[matthiaswelz]

The more I think about, the less I am convinced that just changing the priority would really fix this thoroughly. I think that Retry actually only makes sense in combination with REQUIRES_NEW - otherwise, the retry attempts might still end up sharing the same transaction with all kinds of difficult to diagnose side-effects. So for my use case, I actually want to enforce that Retry is only used with REQUIRES_NEW (because I think that constellation should be “safe”). That’s why I also added the other interceptors which throw an exception when trying to retry a method with TxType.REQUIRED or MANDATORY.

[Ladicek]

As I said on the SmallRye Fault Tolerance issue, 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.

[matthiaswelz]

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

That is a valid point. Maybe I need to rethink my use-case again.
Thanks again for the help!