The scope of multi-tenancy in JPA 2.1 is pretty much set it seems, its
just details at this point. And that scope is decidedly different from
what I did for Hibernate. What we have in Hibernate is actually more
encompassing.
The terms being used to describe the differences are PaaS versus SaaS.
What we have in Hibernate falls into what the spec committee is calling
the SaaS category, essentially the ability to run one instance of the
application (and therefore one instance of Hibernate) simultaneously
handling multiple tenant requests. This is stated to be outside the
scope of multi-tenancy for JPA 2.1. Instead JPA 2.1 will support what
the committee is calling PaaS category, essentially multiple instances
of the application (and therefore multiple instances of Hibernate) would
be needed to handle multiple client requests.
Essentially, you could largely achieve what is planned for multi-tenancy
in JPA 2.1 using JPA 2.0 or earlier. But there will be some caveats to
multi-tenancy in JPA that we will need to deal with, which I wanted to
start discussing.
First I think we should completely not use the existing multi-tenancy
stuff in our support for JPA 2.1 multi-tenancy. Hibernate
multi-tenancy, as it exists already, has some "overheads" thAt simply
are not needed for the JPA use-case. For example, in Hibernate
multi-tenancy (or "Saas multi-tenancy"), there is a need to know which
of multiple available pools to use for getting Connections for use with
particular tenants. But that is simply not needed for JPA multi-tenancy
(or "PaaS multi-tenancy") because that running JPA provider instance can
handle only one tenant at a time. Similar deal with second level cache
keys: no need to encode tenant id into the key. That app will hold only
one tenant's data (unless multiple apps share the same cache instances,
but that's handle-able by prefixing the regions per app/tenant).
If we do end up leveraging the existing multi-tenancy support, we will
additionally need to know the type of multi-tenancy in effect. Here I
mean this question of SaaS versus PaaS rather than the question of
SEPARATE_DATABASE versus SEPARATE_SCHEMA versus DISCRIMINATED.
JPA is proposing some limitations to available features based on the
type of multi-tenancy (if any) is used in the application that we should
go back and look at, even for our SaaS stuff. For example, in the
SEPARATE_SCHEMA the current proposal is to disallow the deployment from
referencing schemas/catalogs at all, which is a good idea. There is
also proposed limitations on native-sql queries such that:
1) they would not be portably available if using DISCRIMINATED, although
persistence providers could choose to support it if they can handle
injecting any needed discriminator fragments
2) could not reference schemas/catalogs in the SEPARATE_SCHEMA, which is
totally inline with the limitation on naming schemas/catalogs in general
in SEPARATE_SCHEMA.
Personally, I find all of the proposed limitations outlined above
reasonable. There is a question of whether we would want to support
native-sql queries in the DISCRIMINATED case. Take an example where the
user supplies a query like [select ... from CUST_TBL c]. Obviously we
need to limit that to return just their data, so we would need to
instead pass a query along to the database like [select ... from
CUST_TBL c where c.tenant = 'acme'] (assuming 'acme' is the current
tenant identifier). It is a lot to bite off to support this
unilaterally, because often folks are resorting to native-sql queries
because they need to leverage some db-specific SQL syntax/feature and
that is essentially impossible to properly parse and interpret. One
option is that we could instead allow a placeholder: [select ... from
CUST_TBL c where c.tenant = ${tenant}]. But even here we still have
difficulty with being able to guarantee that we catch all cases. So in
the end, I am not sure this is something we should be doing.
Anyway, if y'all have thoughts I'd like to hear.
--
st...@hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
