I would go with 1 session factory per tenant (assuming all the data is located within that single database for the tenant). create a HandlerSelector implementation to select the correct database.
Ayende has post about this technique: http://ayende.com/Blog/archive/2008/10/05/windsor-ihandlerselector.aspx You could probablly extend the AR facility to load new session factories on the fly (similar to log4net watching the log4net.config for changes) On Jun 15, 9:43 am, Brian DeMarzo <[email protected]> wrote: > 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 ashttp://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 -~----------~----~----~----~------~----~------~--~---
