On Jan 3, 2011, at 10:29 , Ivo Ladage-van Doorn wrote: > First of all, I believe that we must accept the fact that there will be > situations in which multiple tenants are hosted by the same OSGi container. I > think there will be several use cases in which we cannot effort to start an > isolated container for each tenant, for resource consumption reasons or other.
Are you sure of that? Is the amount of data per tentant so small that the overhead of an extra container is actually the bulk of the data? If that is really the case, isn't your notion of a tenant way too fine grained in that case? What other reasons? > That means that we will have to deal with the fact that some services will be > tenant aware while others will not. If a developer creates a service that is > tenant aware, a separate service instance will be available for each tenant > within that container. For a tenant unaware service, there will be only one > service instance running to be used by any tenant. Maybe. > Now the problem is how service dependencies between tenant aware and unaware > services are resolved. If I created a tenant aware service and have a service > dependency on another service, I need to know if that service is tenant aware > as I need to define the 'tenantid' service property defining this dependency. > But it might be the case that at the time I programmed my tenant aware > service, this other service was not tenant aware but has been made tenant > aware later on. So that means that we need to think of a way that even for a > programmer, it is irrelevant if a service on which his service depends is > tenant aware or not. He should just get the proper tenant aware service > injected. Another way of looking at this: If a service is tenant unaware but it has dependencies on tenant aware services, you have just made it tenant aware by definition. > <braindump> > Now I think the 'context' I'm currently working on might be the/a solution to > this problem. In general a 'context' defines the context of an execution. In > case of a HTTP request for example, it is a 'request context' and the current > tenant could be resolved from the hostname and the current user from the > token cookie. In case of a scheduled job, the context is a 'job execution > context' and the job itself may define the tenant of that context. In case of > a remote service, the context should be send along with the rpc. > Anyway, I think that there is always some 'context' and that context > determines, amongst many other things, the tenant that is 'active' in the > current method invocation. > Now if a service is tenant ware, this just means that it reads the current > tenant from the available context and acts upon. This would add a little more > complexity to the implementation of a tenant aware service as upon each > method invocation it needs to pull this tenant information from the context, > but we could simplify that for example by using AOP (the tenant is an > aspect). However, if the context is available as a service (as I'm planning > to), retrieving the current tenant from the context is rather easy and might > do for the first implementation. > </braindump> > > Please let me know what you think of this brain dump and if it could > contribute to solving our 'tenant problem'. I thought we already dismissed both using some kind of magic "context" stored in a thread local and passing the context around as a parameter to each and every method of a service. As for AOP, I would not want to require everybody working with Amdatu to use that, nor would I want to use it in Amdatu itself. If AOP was such a great idea, it would have been part of Java and OSGi by now. Greetings, Marcel
