CurrentSessionContext implementations cache sessions, per context (thread, managed, JTA). They also check that the session returned is using the right tenant id (according to CurrentTenantIdentifierResolver. An exception is raised other wise.
A user proposed the following adjustments:
CurrentSessionContext implementations will cache sessions per tenant id and per context. For a given context, say the same thread, we would receive different sessions if CurrentTenantIdentifierResolver returns different tenant ids between the calls to Session.currentSession().
The use case is as followed. Some part of the application needs to access the data from more than one tenant (some admin or dashboard). In this case, it might be necessary to have different sessions for each tenant id requested within the same context.
do you think that's a reasonable change?
The context is here https://forum.hibernate.org/viewtopic.php?f=1&t=1035802
Hello, I may be the user at the origin of this feature request.
I think using multiple sessions (each one being tied to separate tenants) in the same context from the SAME session factory is in fact doomed to fail, as it does not properly support second second level caching (as well as session factory stats).
Indeed, considering that the second level cache is at the session factory level, I think data cached on behalf of one tenant would be visible to other tenants, hence breaking the isolation of the tenants. The same goes for session factory stats.
Can you confirm my explanation ?
If confirmed, you can remove the feature request for me because the caching issue is a too important limitation.
As a consequence each tenant must have its own session factory, and the present Hibernate implementations of "current session" are enough to support the uses cases I need.
Florian, the second level cache takes the tenant id into account (except for the SessionFactory operations like evictEntity but that's not relevant here).
You can look at CacheKey.
Great. Thank you Emmanuel.
Now what about session factory stats ?
And are there other mutable data in the session factory that are not "tenant-aware" ?
Well, Session stats will be tenant isolated by definition. I am not sure SessionFactory's stats would make sense if isolated by tenant as a SessionFactory does handle all tenants.
What are your use cases?
This is getting a little complicated by text messages. Emmanuel, if you have some time next month before or after your presentation at Toulouse JUG, maybe we can continue the technical discussion?