Re: Multi-Tenant Data Architecture
Re: Multi-Tenant Data Architecture
- Subject: Re: Multi-Tenant Data Architecture
- From: Henrique Prange <email@hidden>
- Date: Thu, 24 Sep 2009 00:19:47 -0300
Hi Lachlan,
Lachlan Deck wrote:
On 23/09/2009, at 8:46 AM, Henrique Prange wrote:
Chuck Hill wrote:
- problems / load on one tenant do not impact others
- guaranteed that one tenant will not accidently see information from
another
This last one is exactly the reason why we can't have a shared
database at all.
This is what we do .. simply requires an auto injected and'd qualifier +
relevant tables related to said tenant.
That is also a good idea. :)
- some increase in RAM usage due to duplicated loading of code and JVM
If you don't want to do that and are committed to doing this in one
instance, the next best way is to tag the root object with the
tenant. But you said "separate databases", so that is ruled out.
You mean data categorized by tenant?
The application already supports this kind of architecture. We deploy
one application with more than one tenant using a shared database in
very exceptional cases. But that is not the rule. In most cases we
can't take the risk of providing wrong information for a customer.
We've never had that problem - but I understand it's theoretically
possible as is providing the wrong connection dictionary ;-)
Yes. One tenant per instance with separate databases is the safer way.
But has the higher maintenance cost.
Every solution has pros and cons. As I said, I'm not in a hurry to
implement this kind of architecture. But I would like to take decisions
based on good arguments and the result of some experiments. Not because
of a technological problem. As, in theory, EOF can support multiple
databases in one application, I think it is worth making some tests in
this direction.
Anyway, I'm taking all your comments into consideration before I take
the final decision. :)
Cheers,
Henrique
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden