How to prevent rollback of nested service call in Java EE when outer transaction (endpoint) returns an error (REQUIRES_NEW causes deadlock)

In our Java EE application, we have a setup where Service A is an endpoint. In some valid business cases, this endpoint throws an exception and returns an error code to the client — this is expected behavior and cannot be changed.

However, Service A also calls Service B, which is part of another module (included as a Maven dependency). Service B performs an update (clearing activity data), which we want to persist, even when Service A throws the expected error.

The problem: this update is rolled back along with the outer transaction, so the update in Service B is lost.

Here’s a simplified version of the code:

// Service A (has maven dep on ServiceB)
@POST
@Path("/{id}/book")
public Response bookXXXX(..) {
    try {
        serviceB.doSmth(); // should persist even if error follows
        ...
    } catch (SpecificServiceBException e) {
        throw Response.error(Status.CONFLICT, someInfo); // expected and cannot be changed
    }
}

// Service B 
@ApplicationScoped
public class ServiceB {

    @Inject
    private IRepository repository;

    public void deleteActivity(Long key) {
        ActivityEntity activity = find...;

        activity.updateLastDate(null);

        repository.update(activity);
    }
}

We tried using @Transactional(REQUIRES_NEW), but this leads to deadlocks in the database (Oracle). Because the database now has two concurrent transactions and waits for the first ("outer one") to commit and vice versa.

I also tried the recommended TransactionSynchronizationManager from this article to no success.

How can we make Service B’s update persist independently of Service A's transaction, even when Service A throws an exception (as part of normal flow)?

PS: We use Java EE but not Spring.

Solution

Since Service A runs in a (JTA) transaction context that must be rolled back when A throws an exception, nothing that must avoid rollback when A throws can be associated with A's transaction.

Service B is such a thing, or at least its use in conjunction with Service A is. Therefore, in order for B to execute after execution of A starts and complete before execution of A completes, it must be invoked with semantics equivalent to either @Transactional(REQUIRES_NEW) or @Transactional(NOT_SUPPORTED). The latter is presumably not viable, and anyway, both of these share the issue that service B will be unable to access resources locked by the A context from which it is invoked.

Evidently, B does need to access a resource that the associated A transaction locks. This leaves you only two main alternatives:

Refactor A and / or B and / or the underlying resources such that the two services do not (exclusively) access any of the same resources. Any resource that one modifies would be wholly off limits to the other, which might be a broader restriction than it seems on first sight. Having done this, let A invoke B with @Transactional(REQUIRES_NEW) semantics.
Refactor A so that it doesn't invoke B (from within its own transaction context) at all. Presumably, something else would invoke the two, sequentially. That other something might be non-transactional, or it might invoke B with @Transactional(REQUIRES_NEW) semantics.

If neither of these seems viable then that would be a strong sign that your requirements are inconsistent.