Difference in behavior when running a test under TestTransaction

[zanella]

Hi, I've setup a repo(https://github.com/zanella/quarkus-TestTransaction/blob/main/src/test/kotlin/com/example/ServiceTest.kt#L30) which reproduces an issue I'm having on a real codebase:

• There are 2 Entities
• They are joined
• Binding them and persisting to the DB works when NOT running under TestTransaction

The test t0 exemplifies it:

• https://github.com/zanella/quarkus-TestTransaction/blob/main/src/test/kotlin/com/example/ServiceTest.kt#L30
• If executed, it succeds
• If line 29 is uncommented (//@TestTransaction), it fails
• UPDATE 1: After further debugging: Adding a call to entityManager.clear() before the 2nd listAll fixes it, so... guess it's a cache issue when running under TestTransaction ?

Can anyone shed a light on why there's a difference here ?

[quarkus-bot[bot]]

/cc @evanchooly (kotlin), @geoand (kotlin)

[geoand]

cc @yrodiere @gsmet @Sanne

[yrodiere]

Your method f is annotated with @Transactional. This means that:

• When called from an existing transaction, it will just be executed in that transaction with the same Session/EntityManager.
• When called without an existing transaction, it will be executed in a new transaction with its own Session/EntityManager.

In practice, this means the code after the call to f may or may not rely benefit from entities in the first-level cache of your Session/EntityManager, depending on whether you use @TestTransaction or not. If using @TestTransaction you're reusing the same Session/EntityManager and thus manipulating the same entity instances. If not, you're using a new Session/EntityManager and thus manipulating entity instances that were re-loaded from the database.

Anyway... This is more a Hibernate ORM problem than a Quarkus problem. @TestTransaction just wraps your code in a transaction, you'd get the same problem if you started the transaction manually.

[zanella]

I see, do you think it makes sense to move this discussion to the Hibernate-orm github then ?

[yrodiere]

To clarify, I'm not saying the problem is in Hibernate ORM, just that it's with Hibernate ORM and most likely independent from Quarkus. It could be a bug in Hibernate ORM, or it could be a problem in your code or expectations.

If you still have questions, I can answer here or you can reach out to Hibernate ORM devs through these channels. Don't try the GitHub discussions on the Hibernate ORM project, as this is intended for design discussions only, not for usage questions or bug reports.

[zanella]

It absolutely could be a bug in my code, but when not under a transaction Hibernate's cache doesn't "get in the way" (it fetches what I expect it to fetch from the DB), so my guess here is that the fault lies on Hibernate's side.

Also due to the fact that if I clear the cache manually it works.

(My code might be wrong, but the fact that it works under one condition and not the other still makes me point to cache)

[yrodiere]

but when not under a transaction Hibernate's cache doesn't "get in the way" (it fetches what I expect it to fetch from the DB)

I explained that behavior above. When not in a transaction the outer code and the code in f don't use the same session, so they don't use the same cache.

so my guess here is that the fault lies on Hibernate's side.

No, the fact that you use caches in one case and not the other is completely expected behavior.

(My code might be wrong, but the fact that it works under one condition and not the other still makes me point to cache)

Yes it's about (first-level) caches.

[zanella]

It's unfortunate that the first-level cache cannot be disabled then, using TestTransaction becomes a restraining proposition with it :-/

[yrodiere]

I mean, the first level cache is kind of the whole point of Hibernate ORM... There is StatelessSession that doesn't have that cache, but I very much doubt that's what you're after, it's only useful in very specific (mostly read-only) cases.

More likely, you'll want touse QuarkusTransaction to delimit transactions arbitrarily: https://quarkus.io/guides/transaction#programmatic-approach