WAS Liberty doesn't make transaction rollbacks visible

Environment (Required on creation):

WebSphere Liberty 22.0.0.7

Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):

The Camunda process engine supports user-managed transactions. This means that a user may mark a transaction as "rollback only" within their code, and expect any changes made within that transaction to be rolled back.

If this transaction rollback occurs within a process engine Job, then the rollback is seen as a job failure, and the Job retries are reduced.

Steps to reproduce (Required on creation):

Execute the following test cases of the AsyncJobExecutionWithRollbackTest engine IT test on WebSphere Liberty:

• AsyncJobExecutionWithRollbackTest#shouldRollbackTransactionInServiceTask()
• AsyncJobExecutionWithRollbackTest#shouldRollbackTransactionInServiceTaskWithCustomRetryCycle()

Both tests:

1. Introduce an async continuation on a ServiceTask which creates a Job
2. The ServiceTask uses a JavaDelegate that marks the transaction as rollback_only
3. The tests attempt to execute the ServiceTask job

Observed Behavior (Required on creation):

The Job retries are never reduced, so the job remains active and locked.

Expected behavior (Required on creation):

The Job retries are reduced to 0, and an incident is raised.

Root Cause (Required on prioritization):

The process engine expects some type of transaction-related exception (it varies depending on the AS used) to bubble up to the ExecuteJobHelper. The "catch" logic in the ExecuteJobHelper class then reduces the Job retries of the Job.

It seems that WAS Liberty suppresses any type of rollback exception unless the transaction times out for some reason (see code).

Since no exception is thrown on transaction rollback, the Camunda process engine can't handle the job failure. It passes undetected.

Solution Ideas (Optional):

• Camunda can try to detect the rollback and throw an exception itself.
• The Camunda WAS integration can migrate away from using Spring, and use JTA directly. Maybe a more native solution will work better.
• WORKAROUND: users can throw an exception after calling UserTransaction#setRollbackOnly. This would interrupt the job and reduce the number of job retries. - This workaround occurs on WAS9.

Hints (optional):