Is Nhibernate Shards production ready?

At the company I work we have a single database schema but with each of our clients using their own dedicated database, with one central database that stores client contact details and what database the client is using so we can connect to the appropriate database. I've looked at using NHibernate Shards but it seems to have gone very quiet and doesn't look complete.

Does anyone know the status of this project? Has anyone used it in production?

If it's not yet at a point that is considered usable in production, what are the alternatives? The two main ones seem to be:

1. Create a session factory per database and then a wrapper to select the appropriate factory to generate the correct session - this seems to me to have redundant session factories and not too efficient
2. Create just one session factory but when calling opensession pass it an IDbConnection - which would allow the session to have a different database connection.

My concern with 2 is how will NHibernate cope with a 2nd level cache as I believe it is controlled by the session factory - also the HiLo generator uses the session factory I believe. In these cases will having sessions attach to different dbs cause problems? For example we will end 开发者_如何学Pythonup with a MyCompany.Model.User class that has an id of 2 in both databases will this cause conflicts within the cache?

You could have a look at Enzo SQL Shard a sharding library for SQL Server. If you are already using NHibernate there might be a few changes required in the code though

NHibernate Shards is up-to-date with the latest NHibernate API changes and now supports all query models of NHibrrnate, including Linq. Complex scalar queries are currently not supported.

We use it in production for a multi-tenant environment, but there are a few things to be mindful of.

NHibernate Shards has a session factory for each shard, but only uses a single NHibernate Configuration instance to generate the session factories. This approach likely won't scale well to large numbers of shards.

Querying across shards does not play well with paging. It works, but can involve considerable client-side processing. It is best to keep result sets as small as possible and lock queries to single shards where feasible.