[hibernate-dev] multi-tenancy in Hibernate and JPA 2.1

[Steve Ebersole]

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 at hibernate.org
http://hibernate.org