What is your development timeframe? Multi-tenancy is one of the major new
features I envision for AR3. If you say, we will have this going by the end
of the year, you might start with plain AR. The multi-tenancy support will
be added along the lines of:
using (new SessionScope("tenant-id"))
{
// regular AR like before
}
By using this, each tenant can have its own session factory along with all
options this enables (such as different RDBMS types or custom listeners per
tenant).
In conjunction with MonoRail, this boils down to a filter which reads the
tenant from the request and starts the SessionScope for the request. If I
have a user for early adoption and regular feedback, I will be happy to code
this story as one of the first after release of AR2.
-Markus
2009/6/15 Brian DeMarzo <[email protected]>
>
> The Environment: MonoRail, ActiveRecord, Windsor with AR Facility
>
> The Situation: I have one database schema and many databases built
> using that schema. A web application will dynamically figure out which
> one of those databases it is connecting to based on the URL, and will
> need to adjust the database connection string for that request prior
> to any controller processing. (The application is indifferent to which
> database it connects to, since they are all the same schema, just
> different data.) Multiple config files or base classes to handle
> multiple DBs is not possible, as the number of databases could change
> at any time (it's a very dynamic system).
>
> This is an existing app that is being rewritten. It's a baseball game
> with a single huge (~190GB) database, and 98% of the data in that DB
> can be split at the "league" level (about 150 leagues). I'm thinking
> of switching from one big DB to many small DBs for better scaling and
> performance (at the expense of manageability).
>
> The Issue: What is the best way to handle this?
>
> I've searched for answers to this before, and have found a few
> different suggestions, so this post is as much a summary of those
> things as well as a call for suggestions on whether anything I've
> found so far is right, or if there are other solutions.
>
> Some of the suggestions I've found:
>
> 1. Use a custom NHibernate connection provider and inject the
> connection string based on the HttpContext. Side effect: This breaks
> the 2nd level cache, which I perhaps can live with.
> 2. Implement and manage multiple session factories using a solution
> such as http://www.codeproject.com/KB/aspnet/NHibernateMultipleDBs.aspx.
> 3. Use DifferentDatabaseScope in AR -- though comments have said that
> this isn't fully baked yet, this seems to do something similar as #1
> above.
> 4. Wait for NHibernate.Shards to fully bake, and look to incorporate
> that.
> 5. Rely on SQL 2005's horizontal partitioning to avoid the multi-db
> problem and keep everything into a single DB. (Not really a solution
> based on my requirements, but it is an option.)
>
> I'd prefer not to abandon AR or the facility, though I would be
> willing to remove it and just use the NH facility if necessary.
>
> Any thoughts on the matter? At this point, it seems that a custom NH
> connection provider and no 2nd level cache seems most straight-forward
> and reliable.
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Castle Project Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en
-~----------~----~----~----~------~----~------~--~---
