Hi Henrique,
On Sep 22, 2009, at 3:46 PM, Henrique Prange wrote:
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.
Well, then you already know the pros and cons of that scenario! :-)
Pros:
- easy
Not so easy when you have more than 20 different instances (and
counting) running on JavaMonitor. :p
20 does not seem like that many to manage.
- 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.
If it grows to 40, are you planning on having each instance host all
40? I'd look into EOF stack size if you are thinking of having 40 in
one JVM and there is a significant amount of data per tenant. That
might work out to a lot of RAM per instance and so few instances per
machine. It is just something to keep in mind.
- 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?
Yes.
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 backup / restore is a good point. Managing many EOF stacks and
ensuring that one tenant does not see another tenants information
might be just as complex in either scenario.
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?
I have no idea how / if EOModelGroup implements cloning. You would
have to test it. I'd probably choose to do it manually so that I had
control if I ever needed to make any other changes.
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.
Please let us know what happens. This is seldom explored territory.
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
