On 3/29/2012 12:06 PM, Steve Ebersole wrote:
>
>
> On 03/27/2012 05:15 PM, Linda DeMichiel wrote:
>> Hi Mike,
>>
>> On 3/27/2012 11:47 AM, michael keith wrote:
>>> Hi Linda,
>>>>
>>>> (3) Shared table approach
>>>>
>>>> In this approach, database tables are shared ("striped") across tenants.
>>>>
>>>> It is the reponsibility of the persistence provider to provide
>>>> per-tenant isolation in accessing data. This will typically be done
>>>> by mapping and maintaining a tenant ID column in the respective
>>>> tables, and augmenting data retrieval and query operations, updates,
>>>> and inserts with tenant IDs. The use of native queries would need to
>>>> be trapped by the persistence provider and not allowed unless the
>>>> persistence provider were able to modify them to provide isolation of
>>>> tenant data.
>>>
>>> So, portable applications could not use either schemas or native
>>> queries in
>>> this mode, and there will be an opportunity for the application to be
>>> able
>>> to map the tenant id column in each table.
>>>
>>
>> Right
>
> Actually in the SHARED_TABLE approach, the use of schemas and catalogs are actually OK. The idea is that the schema
> layout is the same for all tenants.
>
> Native-sql can be tricky because of the need for handling the tenant-discrimination fragment by either the app developer
> or by injection from the persistence provider. Maybe we want to allow for "placeholder" for this?
>
I wouldn't expect to require that a provider support native sql queries in the striped approach.
A provider might support it, but I wouldn't expect the spec to require that.
>
>>
>>>>
>>>> Ideally, the management of the tenant id should be transparent to the
>>>> application, although we should revisit this in Java EE 8 as we move
>>>> further into support for SaaS.
>>>
>>> For the application to not have to manage tenant ids, I guess the
>>> tenant identifier
>>> would need to be available to the provider on a per-invocation basis
>>> (in a thread
>>> context set by the container)? As you mention, not something that we
>>> necessarily have to worry about now, but just so we know what we will
>>> need
>>> in the future if this is what we want.
>>>
>>
>> Right. For shared application instances we will need this.
>
> You had said this would be available via ENC/JNDI before I think?
>
Right
>>
>>>> I believe that the main use case for the shared table approach is in
>>>> SaaS environments in which a single application instance is servicing
>>>> multiple tenants. This is outside the scope of Java EE 7, so I don't
>>>> think that we need to standardize on support for this approach now,
>>>> although we should not lose sight of it as we standardize on other
>>>> aspects.
>>>
>>> Yes, there is some value in this being available today, though, given
>>> that
>>> some people are doing multitenancy in their own environment, outside the
>>> cloud. I guess it just depends how far we want to go to enable SaaS in
>>> JPA
>>> in this round.
>>>
>>
>> Right. This would be "application-managed SaaS" in my terminology :-)
>> I'm not opposed to considering it in this release, although it depends on
>> time constraints. But it might be advantageous to get more vendor
>> experience
>> first before we standardize.
>
> 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.
>
>>>
>>>> For example, a multitenant application that is designed with the
>>>> intention that separate databases be used might indicate this in the
>>>> persistence.xml as multitenancy = SEPARATE_DATABASE.
>>>
>>> In general I don't think they would even need to specify this, since
>>> this is what
>>> we already assume, isn't it?
>>>
>>
>> But in a cloud environment that may not be the default storage option, so
>> this would indicate that the application was written to *require* use of
>> that
>> strategy.
>
> 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.
> 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.
>
>