I read with great interest as I encountere the same situation some time ago.
In practice (at least in my case), it worked to have the app run on separate
EOF stacks accessing different database. So , it simplified the case to
only have one instance in JavaMonitor for multi databases. However, it is
not the preferred way due to the following same reason..
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.
Shared this too and Chuck has a good point. So I opted to redisign and put
all into single database.
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.
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.
My tests concurred so far. It worked as Chuck mentioned, never use
default<anything>. Called OSC right at the session constructor to be safe.
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.
I run into the similar situation and will be good to know how it goes.
Cheers
Cheong Hee
_______________________________________________
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
