Transaction isolation issue

[jeffjensen]

I'm a long-time dbUnit user and recently learned of this framework, and am trying it on my first product. I really appreciate the annotation approach!

We're encountering some initial issues and looking for how to solve them (other than a feature enhancement :-).

Our environment is Spring Boot, Spring Data/JPA, JPA/Hibernate, with Derby for the test db.

The issue is any simple row manipulation causes failure unless we force a flush, e.g.:

// for inserts and updates:
repository.saveAndFlush(entity);

// for deletes:
repository.delete();
repository.flush();

Because the @DatabaseSetup doesn't commit the prep data (@DatabaseSetup, @ExpectedDatabase, and @DatabaseTearDown run in the same transaction), problems exist with isolation levels disallowing dirty reads and sometimes false-positives based on the database. In my experience, it is better if all of the above steps run in their own transactions. In my prior work using dbUnit directly, the test/dbUnit and the production code each have their own connection and therefore all steps run in separate transactions so never encounter these problems.

How are others working around this without config option to the three annotations to have them each start and commit their own transaction?

[xtea]

+1 , I have the same issue.

[smmribeiro]

+1, me too!

[alvin-xu]

+1

[philwebb]

I don't have an immediate answer I'm afraid. If anyone has time to put together a pull-request I'll happily take a look.

[pecoraladi]

Why was this just closed? It's still broken!! Your library doesn't work with @Transactional methods. So that rules out using it with lazily loaded JPA entities i.e. I would say MOST of us?