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.
Using @Transactional(REQUIRES_NEW) was a natural idea but lead to deadlock because both transactions might try to lock the same table and Oracle doesn’t support true nested transactions.
We solved this by using CDI events with TransactionPhase.AFTER_COMPLETION instead.
The key idea is:
Instead of performing the update directly in Service B we fired a CDI event.
The event observer listens with @Observes(during = TransactionPhase.AFTER_COMPLETION).
This means the observer will be triggered after the outer transaction completes, regardless of whether it commits or rolls back.
The observer method is marked @Transactional, so it runs in a new clean transaction, without interfering with the original one.
This avoids the deadlock and allows us to persist the update even though Service A throws an error.
At the time the observer is triggered (AFTER_COMPLETION) the original transaction has fully ended. There's no transaction context left, so we're free to start a new one (via regular @Transactional) without Oracle getting upset about conflicting locks.
This pattern assumes:
It's running in a full Java EE / Jakarta EE container like WildFly, JBoss, Payara, or GlassFish.
CDI is available, and you're using container-managed transactions (@Transactional).
If you're on plain Tomcat, you'll need to add CDI support yourself (e.g. using Weld SE) — it doesn’t support this out of the box.
// Service A
try {
serviceB.fireClearEvent();
throw new BusinessException(); // triggers rollback
}
// Service B
event.fire(new ClearActivityEvent(key));
// Observer
@ApplicationScoped
public class ClearActivityEventObserver {
...
@Transactional
public void handle(@Observes(during = AFTER_COMPLETION) ClearActivityEvent event) {
// Update the entity in a new transaction
}