Comments on: Is This A Good Approach For Multi-Tenancy Or Not?

By: Christophe Fouquet

Christophe Fouquet — Mon, 05 Jan 2009 20:13:40 +0000

I am doing almost what you are doing.
We have a master and instance sites DBs.
However I do not require each tenant to have its own VDir (AppDomain). Instead, I use a multisite provider to map the “tenant code” in the URL (www.site.com/tenant1/default.aspx) to the actual physical file.
The end result is that I have one single appDomain. This saves memory.
The tricky part is not to use static variables to hold site state but use caching instead (Enterprise library) with the site id as part of every key.
Another big plus is the way we manage localized strings (in the DBs) for each site where we optimize which strings to load for each DB. Since 99% of the strings are the same for all site we can really optimize what strings to cache. This is a long story I cannot describe here.

By: Dew Drop - December 18, 2008 | Alvin Ashcraft's Morning Dew

Dew Drop - December 18, 2008 | Alvin Ashcraft's Morning Dew — Thu, 18 Dec 2008 15:46:48 +0000

[...] Is This a Good Approach for Multi-Tenancy or Not? (Davy Brion) [...]

By: Paul Cowan

Paul Cowan — Thu, 18 Dec 2008 08:29:41 +0000

>> still not sure if i’d be better off with with separate application instances

This approach really works for me. As long as all code bases are the same and you don’t start tinkering with individual instances then it really is the least friction.

I’ve been going with my code base for over a year and I just think my problems would multiply everytime the app. scales.

Anyway just my opinion.

By: trasa

trasa — Wed, 17 Dec 2008 23:11:22 +0000

Just another data point and not advocating for/against anything here, but… I have a client who has just recently migrated from a multitenancy situation very similar to what you describe back to a “single” db / “single” web app model.* The maintenance headaches of 200 very complicated databases and application web sites grew into a crushing burden. Even trivial changes became marathons of change management.

This does have the tradeoff of making the application code more complicated.

* for certain values of “single” as they use a web farm, load balancing tricks, etc. to manage the physical demands.

By: Davy Brion

Davy Brion — Wed, 17 Dec 2008 22:33:35 +0000

hah… i can’t believe i didn’t think of that. I’d keep the cache region out of the config file though… seeing as how i’m already providing the tenant’s specific connectionstring to the SessionFactory in code, i can just as easily use a tenant-specific cache region there as well

thanks for the tip

still not sure if i’d be better off with with separate application instances then, or to try to serve all the tenants with one instance

By: Paul Cowan

Paul Cowan — Wed, 17 Dec 2008 21:54:23 +0000

I have a multi-tenant app with a db for each database and I have a web stie for each customer.

I use memcached as my cache provider

I just use specify a different cache.region for each web site.

Here is an example from one of my Windsor.boo files.

cache.region_prefix=’continutiy2′

Words for me.