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