• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Multi-Tenant Data Architecture
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multi-Tenant Data Architecture


  • Subject: Re: Multi-Tenant Data Architecture
  • From: Lachlan Deck <email@hidden>
  • Date: Wed, 23 Sep 2009 11:34:12 +1000

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.


- 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 ;-)


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?

Very good point. But likewise shared app instances (as we use) must be updated simultaneously also.


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.

with regards, --

Lachlan Deck



_______________________________________________
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


  • Follow-Ups:
    • Re: Multi-Tenant Data Architecture
      • From: Henrique Prange <email@hidden>
References: 
 >Multi-Tenant Data Architecture (From: Henrique Prange <email@hidden>)
 >Re: Multi-Tenant Data Architecture (From: Chuck Hill <email@hidden>)
 >Re: Multi-Tenant Data Architecture (From: Henrique Prange <email@hidden>)

  • Prev by Date: Re: Multi-Tenant Data Architecture
  • Next by Date: Re: Multi-Tenant Data Architecture
  • Previous by thread: Re: Multi-Tenant Data Architecture
  • Next by thread: Re: Multi-Tenant Data Architecture
  • Index(es):
    • Date
    • Thread