Deepak,
Thanks for the feedback.
We agree with you about the scope of the work involved, which
is one of the reasons we have decided not to propose support
for multi-tenant application instances as part of this JSR.
It is definitely something we expect to consider for Java EE 8,
however.
regards,
-Linda
On 6/3/2011 4:13 AM, Deepak Anupalli wrote:
> Hi All,
>
> I think a greater value add and challenge would be to support multi-tenant capability to an application, rather than to
> the platform. Moving forward, "multi-tenancy" and "scalability" are the two major aspects every application architect
> would need to chalk out.
>
> Though application multi-tenancy is something the application needs to build, a lot of work needs to be done on top of
> the existing JDBC/JPA/Servlet contracts in order to really achieve this. May be the expert group should focus more on
> this aspect.
>
> -comments-
>
> ----- Original Message ----- From: "Jason T. Greene" <jason.greene_at_redhat.com>
>
>
>> On 6/2/11 12:47 PM, Antonio Goncalves wrote:
>>
>> -snip-
>>
>>> Correct me if I'm wrong, but latelly I've been earing a lot about
>>> multi-tenant. It looks to me that the world is moving the other way now.
>>> Application servers, databases... tend to be lighter and lighter in
>>> terms of resources. So why bother having multi-tenancy ? Just
>>> instanciate several servers or DBs and each instance only hosts one
>>> application.
>>
>> This is essentially my thoughts on multi-tenant single JVM PAAS, but also for a number of other reasons:
>>
>> 1. Security - Without major changes to the SE JVMs, it will be nearly impossible to prevent one hostile app from
>> having the ability to interfere with another. The JVM security manager isnt really a good fit for a multi-tenant
>> environment, at a minimum it would be very difficult to manager. Also there is really no such thing as a heap safe
>> guard, so it's possible that one tenant could somehow gain access to another's memory.
>
> Completely Agree. In a multi-tenant platform, things like classloaders, static registries etc. can really become a
> nightmare, forcing the containers and applications to be re-engineered.
>
>> 2. Robustness - One bad/broken jar can easily crash the entire server, since there is no limit to the amount of cpu
>> and memory it can use.
>> 3. Resource tracking fairness - With the state of the current SE JVMs, it's not really possible to bill usage fairly.
>> You could track the number of requests, possible connection pool usage, and invocation counts, but these are not
>> necessarily a fair representation of hardware resource cost.
>
> Yes, it is very difficult to meet customer SLAs. I'm not sure if tracking Java EE resource usage opens up a new business
> model for the PaaS vendors.
>
>> 4. Complexity - Trying to get all of the EE services to "partially" adress the above problems (the best we can hope
>> for given the state of SE) will lead major changes to probably every EE API we have, and will likely make all of the
>> implementations far more complex.
>>
>> All of these issues are pretty much solved by having multiple processes which can then take advantage of the
>> underlying OS that has been solving these problems for decades. Having each of those processes be a JVM works great
>> today, however, it does waste memory since there is no class/data sharing*,**.
>
> Yes, this model has been cost-effective and practical for hosted applications.
>
>>
>> It's a shame that the work behind MVM didn't continue, had it been further along, it might have fit our needs.
>>
>> If the goal, however, is to make it easier to build SAAS applications that actually sounds achievable.
>>
>> [*] I realize openjdk has a class sharing feature but it is very limited (client only, inteded for bootclasspath
>> only), and requires that you save memory dumps (so not practical).
>>
>> [**] Certain non-certified JVMs (Dalvik), and other research projects have implemented multi process class file sharing.
>>
>> --
>> Jason T. Greene
>> JBoss, a division of Red Hat
>
> -Deepak