Re: [hibernate-dev] multi-tenancy in Hibernate and JPA 2.1
On Wed 04 Apr 2012 04:26:30 PM CDT, Steve Ebersole wrote:
> I am not sure how the PaaS multi-tenant config will look like
exactly
> but if we can
> automatically prefix the 2LC regions without adding an explicit
> mandatory property
> that would be nice.
Sure. The problem is that in the JPA-supported PaaS model, there is
only really a need to know the tenant identifier when using
SHARED_TABLE approach. There is a part of the proposal about making
the tenant identifier available via ENC/JNDI. However, given that only
the SHARED_TABLE approach (what we call DISCRIMINATED btw) in JPA
needs access to it, I was not clear if that would be available to all
approaches. But even there, I am not sure the ENC entry would be
available when the EMF is getting built. This ties into THE critical
difference between the multi-tenancy support I did already and what
JPA is proposing: namely, Hibernate multi-tenancy supports a single
SF/EMF instance serving multiple tenants, whereas the JPA model would
constrain one EMF to serve a single tenant.
So short answer.. I don't know either. But if it the tenant identifier
is know when building EMF/SF, then yes, the plan was to use region
prefixes.
Just clarified that:
a) the tenant identifier would be made available regardless of the
multi-tenancy approach,
b) the tenant identifier would be made available when the EMF/SF is
starting up; not via JNDI though, the container is expected to pass it
along to the JPA provider via createEMF call.
So it looks like there will in fact be an explicit config setting for
this. Additionally, we are probably going to need another new setting
to indicate whether to enable single-EMF-serves-one-tenant versus
single-EMF-serves-multiple-tenants support (good name suggestions for
this?).
Also, it looks like JPA will not standardize an annotation for naming
the tenant identifier column in mappings for the SHARED_TABLE
(DISCRIMINATED) approach. So we need to decide if we are going to
supply our own annotation or fall in line with the JPA assumption that
the column would just be named the same for all shared tables.
Still one more consideration is whether (and if so, how) we want to
allow for mixed multi-tenant and non-multi-tenant data. Imagine a
trivial example of a COUNTRY code-set table, where all tenants are
sharing that data. This is really just a concern with SHARED_TABLE
multi-tenancy, although even in the other 2 approaches it would be nice
to know that as we could limit second-level caching footprint for that
shared data. Basically I see opt-in and opt-out as the 2 options here.
Personally I prefer that if multi-tenancy is enabled that we assume
all data is multi-tenant and any shared data would need to be opted-out.
I can see 2 opting-mechanisms:
a) mapping data (annotation)
b) config property (hibernate.multi_tenancy.shared_entities
Any other suggestions/thoughts?
--
steve(a)hibernate.org
http://hibernate.org