quarkus: Event Observer BEFORE_COMPLETION transaction timeout causes strange behaviour

Describe the bug

If you use BEFORE_COMPLETION events and a transaction timeout occurs during that event the expected rollback does not work like expected.

Expected behavior

Current transaction is rolled back.

Actual behavior

In our project (with postgresql) the commit happens despite timeout and manually calling setRollbackOnly(). (with and without the setRollbackOnly) When we attempted to reproduce this within the hibernate-orm-quickstart (with h2) project the table was deleted instead. Both behaviours should not happen.

How to Reproduce?

start mvn test of reproducer reproducer_timeout.zip

Is there anything incorrect on how we use the event? From the documentation setRollbackOnly is allowed in the BEFORE_COMPLETION event. It works without the timeout.

    @Inject TransactionSynchronizationRegistry registry;

    public void beforeCompletion(@Observes(during = TransactionPhase.BEFORE_COMPLETION) Fruit exampleEvent) {
        try
        {
            // causes timeout of transaction
            Thread.sleep(4000);
        }
        catch (InterruptedException e)
        {
            e.printStackTrace();
        }
        // should do rollback
        registry.setRollbackOnly();
        System.out.println("done with example event");
    }

Output of uname -a or ver

MINGW64_NT-10.0-19042 w61p08 3.1.4-340.x86_64 2020-05-19 12:55 UTC x86_64 Msys

Output of java -version

java 11.0.5 2019-10-15 LTS Java™ SE Runtime Environment 18.9 (build 11.0.5+10-LTS) Java HotSpot™ 64-Bit Server VM 18.9 (build 11.0.5+10-LTS, mixed mode)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.3.1.Final and 2.2.X

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.6.3

Additional information

No response

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 17 (12 by maintainers)

Most upvoted comments

At the same time, there are a couple things that Agroal does well under the circumstances:

We agree and are switching from Transactional Driver to Agroal for standalone narayana (https://issues.redhat.com/browse/JBTM-3439), we’ve already started on the task.