Re: Multi-Tenant Data Architecture
Re: Multi-Tenant Data Architecture
- Subject: Re: Multi-Tenant Data Architecture
- From: Henrique Prange <email@hidden>
- Date: Tue, 22 Sep 2009 19:46:11 -0300
Hi Chuck,
Chuck Hill wrote:
The easiest, and perhaps best, way to do this is to have different
instances for each tenant. The configuration (in JavaMonitor or
elsewhere) can then specify the database.
That is our current way to deploy the application.
Pros:
- easy
Not so easy when you have more than 20 different instances (and
counting) running on JavaMonitor. :p
- 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.
Cons:
- more instances to administer
That is our main concern. Today we have 20 instances, but this number is
likely to increase considerably in near future.
- 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.
Writing a bug free multi-tenant application with shared data is time
consuming and expensive. In the case of this specific application is
also too risky. Also, a shared database make the backup/restore process
very difficult. You can backup everything easily, but how to revert the
data for a single tenant?
The only way that I can think of to accomplish what you want is to
create an EOModelGroup for each tenant. A separate copy of each model
will need to be loaded into each group and the database connection
information set for that tenant. Each EOModelGroup will serve as the
basis for a new EOF stack (rooted at EOObjectStoreCoordinator).
Miguel gave me this same idea off-list. So, I think that is the way to
go. :)
Sorry for the stupid question, but would be enough to get the
defaultModelGroup, clone it and change the URL for database connection
on each cloned model? Or is it a better/safe idea to create one by one
and load models as if it were the first time?
When a
session is created, you will need to ensure that all editing contexts
created for that session use the correct EOObjectStoreCoordinator. You
will also want to ensure that you don't use default<Anything> in your
code (defaultEditingContext(), defaultModelGroup() etc.) as these are
unlikey to return objects from the correct EOF stack. Caveat: this is
theoretical, I don't have any experience doing this. I don't think that
many people have done this, so you run the risk of finding bugs in
seldom executed EOF code.
Thank you very much! We are not in a hurry to make this change in our
application, but we are worried about future. I'll try to make some
tests following your advices and see what happens.
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