I have been involved in a few applications that require this type of architecture. For the database I would suggest the following (I am assuming you are using SQL Server):

1. Create only one instance of the database with all the customers data (see below for more information regarding partitioning).
2. Add an account column to each table (you can do this with script) with a default value of suser_sname() (This function returns the name of the currently logged in user, basically you are implementing row-level security)
3. For each customer, create a separate login to SQL Server
4. Create a view for every table that looks like this:

SELECT col1, col2, col3 FROM mytable WHERE account = suser_sname()

5. Update your DAL to query the views and not the tables. Inserts, updates, deletes will still work.
6. Develop some code so that when a user logs in, it checks what their associated customer login is, subsequent database calls should be made with this login.

This works really well. In terms of maintenance, you only ever work with one database. If you are fixing a bug or checking out an issue for Customer B, you can log into the database with customer B’s associated login. If you run a query that looks like this “DELETE FROM vw_mytable” you will only every affect Customer B as the views have effectively partitioned your context. I would suggest adding each customer’s account to a database role which only allows inserts, update, deletes for the relevant views (ensures you haven’t missed a table).

Hope this helps.
Rohland

The application had to service different mobile network operators’(the tenants) devices as part of the initial phone configuration workflow. Each tenant had a contract definition which included handsets that they supported, associated device settings(as xml documents).

Access to the application was via the following mechanism

configuration.service.com?contractId=00000000239. This triggered a FrontController that went about initialising the session and loaded core data in the cache and keyed it by contractId, peripheral data was lazy loaded.

tenantb.ourproduct.com – that is the most common way to do that, the other way of doing that is to have a common login page and redirect base on the user object (shared across all tenants).
The 2nd Level Cache is great, but it doesn’t differentiate between multiple SessionFactories. – not quite accurate, you can define regions, and IIRC, it uses the session factory name as part of the cache space.
I wouldn’t go with the virtual dir path, myself.

Then you aren’t doing multi-tenanting, at least in that most if not all descriptions of multi-tenanting that I have encountered have required that multi-tenanting be taking place within a database instance (as doing multi-tenanting up at the web tier is the easy part regardless of how the database instances are set up.)

“Each database will have an identical structure”

Good call. Each and every time I’ve seen people go down the path of having different schema per instance it has become a very large headache.

“Our first idea was to have one actual instance of the application”

Also a good call in general, but make sure to at least consider being able to configure your load-balancing so as to focus a given client’s users on a given subset of servers so as to maximize web tier in-memory cache coherency and to keep from overrunning your database servers’ ability to accept incoming connections for each schema instance. You’re going to need to monitor, analyze, and adjust a number of balancing factors between things like the number of web servers and the number of database servers, clients per web server, maximum db connections per web-server-client-instance, the number of db schema instances per physical db server, etc.

“We still have the benefit of one physical deployment, and because each tenant’s ‘virtual’ application runs in its own AppDomain, the caching problem is no longer an issue.”

But memory usage will then be an issue. This will in turn push you towards installing components in the GAC so as to get shared code in memory. This in turn will push you towards having to deal with annoying component deployment and versioning issues. I’m not going to suggest that this is a horrible route, or that the alternatives are perfect, but do be aware that there be dragons down the path of separation by AppDomain.

Jeremy