>>>> 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?
Will the tenant identifier be available in ENC/JNDI regardless of
strategy being used?
>>>> 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.
Will we at least have a standardized annotation for mapping the "tenant
identifier" column?