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      (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

Reply via email to