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

From: Linda DeMichiel <>
Date: Fri, 30 Mar 2012 12:49:30 -0700

On 3/29/2012 4:07 PM, Steve Ebersole wrote:
>>> I would at least like to see the annotation for naming the "tenant
>>> discriminator" column standardized. I think that's
>>> the most crucial piece from app developer perspective.
>> But if the app itself is truly managing multitenancy (rather than the
>> provider), then this
>> column could be named anything. If the provider is "multitenancy-aware",
>> the provider
>> could plausibly make this column transparent to the app.
> Sure, but the persistence provider needs to be made ware of that name. That would be the point of this annotation - it
> would name that column.
>>> Perhaps I missed this in the initial reading also, but I did not see
>>> specifics on how JDBC Connections were expected to
>>> be made available as part of this.
>>> I think maybe the realization I am starting to come to is that this
>>> proposal is really just assuming that a given
>>> instance of the jpa provider would only be dealing with one tenant.
>>> Reading back, I guess that is what you meant with
>>> the "single-instance SaaS case" comments.
>>> Am I correct in this new-found realization?
>> Yes.
> Well supporting the SaaS case is certainly more complicated than the PaaS case...
>>> If that is the case, I actually see no difference between
>>> SEPERATE_DATABASE (and even SHARED_SCHEMA for most databases)
>>> and what JPA does today.
>> You mean SHARED_DATABASE rather than SHARED_SCHEMA, right? Except today,
>> JPA assumes that the
>> app has access to more than just the default schema.
> Ah, yes. These are not the terms I am familiar with...
> Well I think there is another assumption here about why people choose SEPERATE_DATABASE over SHARED_DATABASE. Some, I am
> sure, do desire there to be separate schemas available. But I think plenty of others chose it simply because it is more
> secure and more scalable since they would have dedicated instance tuned for their data (based on SLAs, etc). I am
> certain not everyone chooses SEPERATE_DATABASE to leverage multiple schemas; so in those cases the two are interchangeable.

Good -- thanks, this is helpful feedback.