Error wihile runnging Test: No EntityManager with actual transaction available for current thread – cannot reliably process ‘persist’ call

by

Summary

During an integration test run, the TransactionRequiredException was thrown:
No EntityManager with actual transaction available for current thread - cannot reliably process 'persist' call.
The application itself ran fine, but the test failed because the transactional context was not correctly propagated.

Root Cause

  • The test class is annotated with @Transactional, which starts a transaction before the test methods.
  • MockMvc performs the request outside of that transaction.
  • Hibernate tries to persist an entity during request handling, but it sees no active transaction, hence the exception.

Why This Happens in Real Systems

  • In production, the container typically wraps each HTTP request in a transaction (e.g., Spring MVC with @Transactional on controller methods or services).
  • During tests, especially integration tests, the request is simulated via MockMvc; the transaction started by @Transactional at the test level does not automatically extend into the MVC stack.
  • This mismatch leads to Hibernate complaining that there is no active transaction when attempting to write to the database.

Real-World Impact

  • The entire test suite halts on the first failure, increasing feedback time.
  • Developers cannot rely on integration tests to catch data‑layer bugs.
  • In CI pipelines, failed tests can mask real issues, reducing overall quality.

Example or Code

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
@AutoConfigureMockMvc
@DisplayName("Saving Endpoints Integration Tests")
@Transactional  // Transaction starts here, but not applied to MockMvc request
public class AuthControllerIntegrationTest {

    @Autowired
    private MockMvc mockMvc;

    @Autowired
    private ObjectMapper objectMapper;

    @Test
    void testLogin() throws Exception {
        getToken("admin", "azerty");
    }

    private LoginResponse getToken(String username, String password) throws Exception {
        final LoginRequest loginRequest = new LoginRequest();
        loginRequest.setUsername(username);
        loginRequest.setPassword(password);

        MvcResult result = mockMvc.perform(post("/api/auth/login")
                .contentType(MediaType.APPLICATION_JSON)
                .content(objectMapper.writeValueAsString(loginRequest)))
                .andDo(print())
                .andExpect(status().isOk())
                .andReturn();

        return objectMapper.readValue(result.getResponse().getContentAsString(), LoginResponse.class);
    }
}

How Senior Engineers Fix It

  • Remove @Transactional from the test class and instead rely on the transactional handling of the application layer (e.g., annotate service methods with @Transactional).
  • Add @Transactional to individual test methods that require a transaction, ensuring it is applied only where needed.
  • Configure MockMvc with a @Transactional proxy by adding spring.jpa.open-in-view=true and using @Transactional on your controller/service.
  • Use @DirtiesContext if you need a fresh context per test to avoid stale data.

The most common pattern:

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
@AutoConfigureMockMvc
class AuthControllerIntegrationTest {
    // ...
}

and let the controller/service layer handle the transaction lifecycle.

Why Juniors Miss It

  • They assume @Transactional at the test level propagates automatically into the mock MVC request.
  • They overlook that MockMvc performs a stand‑alone MVC call, independent of the transaction started by the test.
  • They rarely use @SpringBootTest’s transactional propagation because it feels “overkill” compared to @DataJpaTest.
  • They fail to read the exception message carefully, thinking it’s a generic Hibernate bug rather than a transaction scoping issue.

Leave a Comment