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
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
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
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
Yes, there is some value in this being available today, though, given
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
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
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
[jsr338-experts] Re: [jpa-spec users] Re: support for multitenancy
[jsr338-experts] Re: support for multitenancy