Should you use the same connection string when using NHibernate and ASP.NET

Question

I have just re-implemented an ASP.NET web application that uses NHibernate to use a session per request (using an IHttpModule). The SessionFactory is created at the start of the application using a connection string from the web.config file. The SessionFactory is then stored and sessions created and released using a thread-safe, lazy singleton.

This means that if say 20 users are using the application the same user (as specified in the connection string in web.config) is used when creating any connections to the database - is this best practice? Will SQL Server Express complain about the number of connections eventually? (as connections are created and released per request this may not be a concern in practice).

In my old architecture a connection was created using the user name of the current user - is there any advantage to this (perhaps if there is are security restrictions for the logins of each different user).

When using a thread-safe, lazy singleton (like below) which contains the SessionFactory and manages sessions, I believe this is available site wide wide e.g. 2 users accessing the application from different PCs will use the same instance?

public static NHibernateSessionManager Instance
{
  get
  {
    return Nested.NHibernateSessionManager;
  }
}


private class Nested
{
  static Nested() { }
  internal static readonly NHibernateSessionManager NHibernateSessionManager =
    new NHibernateSessionManager();
}

Answer 1

As long as your connection strings are equal (e.g. you don't insert a user ID for the current user) You'll get better perf from both sides of your app by using the same string.

Answer 2

It's definitely a best practice if the goal is to increase performance. Using one connection string enables connection pooling.