Context propagation with fault tolerance @Retry

[sbeigel]

I'm using @Retry on a method the does look up entites in the database to check some status. When the code is "retried", the *.findById(...) calls seem to return the entity from the context/session that was active on the first run. I guess that's intentional and due to the context propagation. Is it possible to get rid of the automatic context propagation when retrying the failed method? I tried:

@CurrentThreadContext(propagated = {}, unchanged = ThreadContext.ALL_REMAINING)

but it didn't work. In my case, I need a "fresh" context (at least tx context) to get current "versions" from the database (as the entites may be changed by other processes while "retrying" in my use-case.

Here is a simplified (and kind of useless) example:

@Transactional
public String test() {
    // ...

    checkAndDoFoo(id);

    // ...
}

@Retry(maxRetries = 3, delay = 5000)
@CurrentThreadContext(propagated = {}, unchanged = ThreadContext.ALL_REMAINING)
@Transactional
void checkAndDoFoo(Long id) {
    // how to get a "current/fresh" Foo?
    Foo f = Foo.findById(id);
    if (f.status != Status.OPEN) {
        throw new RuntimeException("Still not open");
    }
    // do something with the "OPEN" foo...
}

[quarkus-bot[bot]]

/cc @FroMage (context-propagation), @Ladicek (fault-tolerance), @manovotn (context-propagation)

[Ladicek]

I don't think this has anything to do with context propagation and everything to do with interceptor priorities. It turns out that @Transactional has lower priority than @Retry, so all retries happen in the same transaction. You can change that either by configuration, or by cleverly splitting the method into 2:

@Retry(maxRetries = 3, delay = 5000)
void checkAndDoFoo(Long id) {
    checkAndDoFoo0(id);
}

@Transactional
void checkAndDoFoo0(Long id) {
    // how to get a "current/fresh" Foo?
    Foo f = Foo.findById(id);
    if (f.status != Status.OPEN) {
        throw new RuntimeException("Still not open");
    }
    // do something with the "OPEN" foo...
}

Remember that the checkAndDoFoo0() method must not be private, otherwise it wouldn't be intercepted.

[Ladicek]

Retries are generally a double-edged sword. They may increase resiliency, until they decrease it. I'm generally not terribly happy about them 🤷

[sbeigel]

:)

how can you adjust the priorities on a "per-method" basis to have a tx for each retry? I.e. the checkAndDoFoo(...) method in my example? By annotating it with @Priority? With which value?

[sbeigel]

BTW & FYI, I tried you suggestion with the second non-private method (with @Transactional) -- at least for me to make it work, I had to add TxType.REQUIRES_NEW...

[Ladicek]

There's no way to do it on a per-method basis, the only thing that's possible is global: adjust the configuration of mp.fault.tolerance.interceptor.priority (per https://github.com/eclipse/microprofile-fault-tolerance/blob/main/spec/src/main/asciidoc/fault-tolerance-interceptor.asciidoc).

When it comes to TxType.REQUIRES_NEW, that sounds like a transaction has already been started before the method has been called. There's nothing we can do about that.

[sbeigel]

Thanks!