Wrong tenant-identifier in Envers temporary session

Description

In org.hibernate.envers.internal.tools.EntityTools line 52 a temporary session is created, but it has the wrong tenant-identifier and this throws an exception where the multi-tenancy strategy selects a different datasource and the runtime environment does not allow multiple datasource during a transaction.

This might have been introduced by HHH-13565.

Environment

None

Activity

Show:
Chris Cranford
November 6, 2019, 3:21 PM

The underlying issue is that previously the SessionBuilder was resolved at the call site when openSession and openTemporarySession were invoked, so the tenant identifier was resolved at that point as well. The change introduced by changes this and now the tenant is resolved much earlier during SessionFactory construction and won't be re-resolved later.

I see there being 3 options here depending on what you guys believe makes the most sense:

1. Restore the behavior previously and resolve SessionBuilder at the call site like we did before
2. Change how we resolve the tenant identifier so it can be re-resolved like previously
3. Change Envers not to use these methods but basically create the temp-session itself like the old code used to

I'm not opposed to making change (3) if it makes logical sense as we already do something similar in AuditProcess; however, I asked to report this as I'm more concerned with potential regression behavior that the original change may introduce elsewhere.

/ , do either of you have an opinion here on what you think is the best way to fix this for the next release?

Sanne Grinovero
November 6, 2019, 3:41 PM

Hi ! Yes, sorry I am planning to work on later this week. I’ve now assigned this to myself to make it clear.

 

Thanks I didn’t know about this other issue, I’ll make sure to test that I resolved both.

Chris Cranford
November 6, 2019, 3:56 PM

Awesome. I have also committed this to my local repository
https://github.com/Naros/hibernate-orm/commit/5fd5907e4bb05e092970d419cd308ab9b4ce2cd6

If the solution to fix this cannot make it into 5.4.9, could we at least commit the above commit to fix Envers?

Anders Bergquist
November 6, 2019, 10:19 PM
Edited

I opened an issue ~2 weeks ago and I’m pretty sure it’s the same root cause as this issue (linked it as a duplicate). I attached a simple project with a test if that helps.

Sanne Grinovero
November 11, 2019, 10:55 AM

Thanks ! And sorry for the delay, finally getting to work on this.

Assignee

Sanne Grinovero

Reporter

Giovanni Lovato

Fix versions

Labels

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

backportDecision

None

Worked in

5.4.4

Components

Affects versions

Priority

Blocker
Configure