users@jpa-spec.java.net

[jpa-spec users] [jsr338-experts] Re: support for multitenancy

From: Steve Ebersole <steve.ebersole_at_redhat.com>
Date: Thu, 29 Mar 2012 17:49:06 -0500

>> Yes. In my experience, just as you mention, there are really 2
>> distinct categories here. SHARED_SCHEMA and
>> SEPARATE_DATABASE both are largely interchangeable, and then you have
>> SHARED_TABLE. Really the question here lies in
>> which of these 2 categories the deployment can handle. What you say in
>> regards to SHARED_SCHEMA and SEPARATE_DATABASE is
>> absolutely correct, if the app can handle using one strategy it can
>> handle the other; but that same app may or may not
>> be able to (or want to) handle SHARED_TABLE. Conversely, an
>> application that is built for SHARED_TABLE could conceivably
>> operate in SHARED_SCHEMA or SEPARATE_DATABASE situations as well
>> (native SQL aside, potentially).
>
> Yes, but the difference here is whether the app is expecting to use
> multiple schemas (or named
> schemas). If so, then SEPARATE_DATABASE and SEPARATE_SCHEMA wouldn't be
> interchangeable, although
> the former could be used in place of the latter. With SHARED_TABLE the
> same issue holds --i.e.,
> if the app were expecting multiple schemas, then the persistence
> provider would have needed to
> have been allocated a database (rather than just a schema).

Totally. That is why I said "largely interchangeable" originally. I
guess my follow up loses the "potentially" slant. But you are
absolutely right.

There are other concrete differences, but those mostly come more into
play in the SaaS domain, which you have stated is outside the scope of
this for 2.1 (how you get Connections, how you ALTER Connections, etc).
  I was just slanted to thinking the SaaS point-of-view since that is
what I did in implementing multi-tenancy for Hibernate. Luckily for me
the SaaS solution encompasses the PaaS domain :D