users@javaee-spec.java.net

[javaee-spec users] Re: [jsr342-experts] proposal for Tenant ID

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Thu, 26 Jan 2012 11:16:26 -0800

Pete Muir wrote on 01/26/2012 02:59 AM:
>
> On 25 Jan 2012, at 22:52, Bill Shannon wrote:
>
>> Pete Muir wrote on 01/25/12 03:48:
>>> Bill,
>>>
>>> It's not clear from the proposal what the *type* of the tenant id would be.
>>> I'm going to assume it's of type String for the discussion below.
>>
>> Yes, although we'll probably need to say something about the characters
>> allowed in the string and the maximum length of the string.
>>
>>> Assuming that this is cleared up, and the JNDI option was taken, we could
>>> update the CDI spec to allow injection of the tenant ID. For example, CDI
>>> could define the qualifier @TenantId, allowing the tenant to be injected via
>>> @Inject @TenantId String tenantId;. I would suggest specifying this in CDI
>>> 3.6 where we allow injection of other Java EE objects which are available in
>>> JNDI, using language like:
>>>
>>> "a bean with bean type java.lang.String with qualifier @TenantId allowing
>>> injection of the current Tenant ID" (I would also need to adjust the
>>> surrounding language as the qualifier @Default is specified in the preamble,
>>> but that is not hard).
>>>
>>> WDYT?
>>
>> For EE 7 we've taken a very simple approach to multi-tenant applications
>> that means each tenant gets its own instance of the application.
>>
>> For EE 8 we'll need to consider whether we should support a model in
>> which multiple tenants share a single application instance. Obviously
>> there are many issues with this, and it may turn out to not be feasible,
>> but...
>>
>> If multiple tenants share an application instance, the tenant ID will
>> need to be different per thread, and thus injecting the tenant ID isn't
>> going to work well.
>>
>> For that reason I'm hesitant to define injection of the tenant ID until
>> we have more experience with multi-tenant applications.
>
> Good point. We could define that the tenant id must be proxied, allowing the actual value to be looked up (e.g. via the JNDI binding or an SPI) at call time. This is how many of the EE injections are handled in practice.

It's hard to proxy a String. This would require us to define a new class.
Without more experience in this area, that seems like overkill.

Again, we *don't* expect most multi-tenant apps to need the tenant ID.
Mostly we're providing it as an escape hatch for those cases we haven't
thought of.