Most of our Quarkus endpoints follow the standard practice in which they're annotated with @Transactional, call into our business layer, and if an exception is thrown the entire transaction is rolled back.
However, for this scenario, we need to execute a database update even if the transaction is rolled back. Our database is MySQL 8.
// Quarkus Resource class
@POST
@Transactional
@Path("/document/generate")
public void generateDocument() {
documentGeneratorComponent.generateDocument(...);
}
Our initial attempt was to use @Transactional(REQUIRES_NEW) to update the status. The problem we're running into is we're getting lock timeout exceptions as I believe both the outer transaction and the nested transaction are trying to update the same tracking record.
@ApplicationScoped
public class DocumentGeneratorComponent {
public void generateDocument(...) {
Long trackingId = null;
try {
trackingId = createTrackingRecord(DocGenStatus.STARTED);
// error prone stuff that may throw
var input = getInputData(...);
docGenService.sendDocRequest(input);
} catch (Exception ex) {
if (trackingId != null) {
updateStatusWithError(trackingId);
}
throw ex;
}
}
// updates tracking record even if error
@Transactional(REQUIRES_NEW)
public void updateStatusWithError(var trackingId) {
updateTrackingRecord(trackingId, DocGenStatus.EXCEPTION);
}
}
Initially, we thought we can remove the @Transactional annotation from the Resource layer and handle the transaction in the component. The problem is other code in our business layer may also need to generate documents and they may do that within the scope of their transaction.
It would be incredibly convenient if there was a simple way to execute code in a callback like the following. Is there a best practice for doing this type of thing in Quarkus?
public void generateDocument(...) {
Long trackingId = null;
try {
} finally {
transactionManager.onCurrentTransactionRollback(
() -> updateStatusWithError(trackingId)
);
// ...
}
// ```
}
I looked into @TransactionScoped beans, but the @PreDestroy is documented as being invoked before the transaction is rolled back and there's an open defect in which it seems the behavior of when it's executed is undefined or inconsistent with the documentation.
There's also transaction listeners but it seems a bit inconvenient to use as they listen on all transactions and not a specific one.
void onAfterEndTransaction(@Observes @Destroyed(TransactionScoped.class) Object event) {
// will be invoked for every transaction in the application, not just the code in question
}
What's the recommended approach? Thanks!
JPA has capability to control the exceptions in which transactions must be rolled back. The @Transactional annotation has two attributes: rollbackOn and dontRollbackOn.
According to the documentation:
The
dontRollbackOnelement can be set to indicate exceptions that must not cause the interceptor to mark the transaction for rollback. Conversely, therollbackOnelement can be set to indicate exceptions that must cause the interceptor to mark the transaction for rollback. When a class is specified for either of these elements, the designated behavior applies to subclasses of that class as well. If both elements are specified,dontRollbackOntakes precedence.
In my solution there's no need start transaction in resource layer but it also works with other transactions.
@ApplicationScoped
public class DocumentGeneratorComponent {
@Transactional(dontRollbackOn = DocumentException.class)
public void generateDocument() {
var trackingRecord = createTrackingRecord(DocGenStatus.STARTED);
try {
var input = getInputData(trackingRecord.id);
// ...
// It was missing in the question, but I assume it would be helpful
// to mark when the document generation finished successfully.
trackingRecord.docGenStatus = DocGenStatus.FINISHED;
} catch (DocumentException e) {
trackingRecord.docGenStatus = DocGenStatus.EXCEPTION;
throw e;
}
}
@Transactional
TrackingRecord createTrackingRecord(DocGenStatus status) {
TrackingRecord record = new TrackingRecord();
record.docGenStatus = status;
record.persistAndFlush();
return record;
}
String getInputDate(Long trackingRecordId) {
if (null == trackingRecordId) {
throw new DocumentException("Invalid tracking record (null).");
}
if (trackingRecordId % 2 == 0L) {
return "FOO";
}
throw new DocumentException("Sometimes it is happen.");
}
}
The sample TrackingRecord entity is:
@Entity
public class TrackingRecord extends PanacheEntity {
@Enumerated(EnumType.STRING)
public DocGenStatus docGenStatus;
}
As you can see the createTrackingRecord(...) method returns the entity instead of its id. That entity is attached to the Persistence Context.
Now, @Transactional annotation is no longer necessary on the resource method.
@Path("/document")
public class DocumentResource {
@Inject
DocumentGeneratorComponent documentGeneratorComponent;
@POST
@Path("/generate")
public void generateDocument() {
documentGeneratorComponent.generateDocument();
}
}
Ok, but what about other business services that
may also need to generate documents and they may do that within the scope of their transaction.
It is also possible.
@ApplicationScoped
public class OtherBusinessService {
@Inject
DocumentGeneratorComponent documentGeneratorComponent;
@Transactional(value = Transactional.TxType.REQUIRES_NEW)
public void whateverBusinessMethod() {
var entity = new CustomBusinessEntity();
entity.name = "John Doe";
entity.persist();
try {
documentGeneratorComponent.generateDocument();
entity.documentGenerated = true;
} catch (DocumentException e) {
entity.documentGenerated = false;
}
}
}
The OtherBusinessService.whateverBusinessMethod() will perist both of CustomBusinessEntity and TrackingRecord entities.
An important thing is that OtherBusinessService or any other business method which handles their own transaction must handle that certain exception with the following ways:
@Transactional annotation's dontRollbackOn attribute.