Assertions.assertTimeoutPreemptively() breaks Spring test transaction rollback

[oopschen]

Overview

We use JUnit Jupiter 5.3.1 in our web project, the assertTimeoutPreemptively() method will break the transaction rollback in spring's testing framework. As we use DataSourceTransactionManager as the main transaction manager, the manager will propagate the transaction in the same thread, not across threads. The assertTimeoutPreemptively() method starts a new thread running our code which differs from the main test thread resulting in transaction propagation breakage.

Steps to reproduce

1. run test code surround by assertTimeoutPreemptively()
2. the test code request a URI in Spring's mocked web environment
3. the URI insert a record to database
4. the record is not rolled back

Context

• 5.3.1 (Jupiter/Vintage/Platform):
• Intellij

Possible resolution

Run test code in main test thread and run timeout in spawned thread.

Related Issues

• Introduce global timeouts for tests #80

Deliverables

• Add note regarding the use of assertTimeoutPreemptively() and the effects on ThreadLocal storage (in general) and with Spring's transaction management (as an example) in ...
  • Javadoc
  • User Guide

[marcphilipp]

That's the documented behavior and the only way to make it preemptive.

@sbrannen Is there a way to make the started thread "inherit" the transaction of the thread that started it?

[sbrannen]

@sbrannen Is there a way to make the started thread "inherit" the transaction of the thread that started it?

No, that is unfortunately not possible.

Spring's transaction management binds transaction state to a ThreadLocal.

Spring's testing support simply builds on that core transaction support. Consequently, it is not possible for the Spring TestContext Framework to switch from a ThreadLocal to an InheritableThreadLocal since transactional application code would not see the transaction state.

A few year's back I did actually switch Spring's transactional support to use an InheritableThreadLocal on a local branch and verified that the testing support then worked with spawned threads; however, we (the core Spring Team) decided not to make that change in core Spring since it would be a breaking change for countless Spring-based projects worldwide.

The only solution I see to this problem is the introduction of support for global timeouts in JUnit Jupiter (see #80), since Spring's transaction would start within the timed thread.

[sbrannen]

For what it's worth, I actually always mention this pitfall when delivering talks on JUnit 5:

https://www.youtube.com/watch?v=K7g2HUhWbNE&feature=youtu.be&t=683

😉

[marcphilipp]

Let's close this issue in favor of #80 then.

[sbrannen]

Reopened in order to add a note regarding the effect of ThreadLocal storage with Spring's transaction management as an example.