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 18:07:24 -0500

>> 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.