Make CurrentSessionContext implementation isolate sessions per tenant id

Description

Today,
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

Environment

None

Activity

Show:
Florian Beaufumé
May 19, 2015, 9:36 AM

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.

Emmanuel Bernard
May 19, 2015, 11:57 AM

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.

Florian Beaufumé
May 19, 2015, 1:45 PM

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" ?

Emmanuel Bernard
May 21, 2015, 9:41 AM

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?

Florian Beaufumé
May 21, 2015, 1:34 PM

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?

Assignee

Unassigned

Reporter

Emmanuel Bernard

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Priority

Major
Configure