Using a static instance of DbProviderFactory in ADO.NET?

I am using the following code in my asp.net app. According to this code, for all users of the app, there will be only a single instance of DBProviderFactory. Will this create a problem in a multi-user environment? So all users would use the the same DbProviderFactory object to create connections. I am not sure if this will create some type of hidden problems in a multi-user environment.

The reason, why I am using a static instance for DbProviderFactory, is so that the GetFactory method is not called everytime a connection needs to be instantiated. This, I think, would make it quicker to get a connection object. Any flaw in my reasoning?

 public class DatabaseAccess
{

    private static readonly DbProviderFactory _dbProviderFactory =
 DbProviderFactories.GetFactory(System.Configuration.ConfigurationManager.ConnectionStrings["DB"].ProviderName);

    public static DbConnection GetDbConnection()
    {
        DbConnection con = _dbProviderFactory.CreateConnection(); 
        con.ConnectionString = System.Web.Configuration.WebConfigurationManager.ConnectionStrings["DB"].ConnectionString;
        return con;
    }
}

It looks fine, but probably will not create interesting efficiencies.

Object creation in .NET is quick. So creating the factory doesn't take a lot of time. Acquiring the connection from a remote database does, but with connection pooling, this normally isn't an issue.

The factory probably doesn't appear to implement any state of it's own & looks like it's probably immutable. So access from different threads is probably okay.

Static objects aren't garbage collected. I doubt the factory will grow in size, so this shouldn't be a problem.

So you avoid a bunch of cheap object creation, a bunch of cheap background garbage collections, and have a minor risk of a derived class actually having state and not being thread safe depending on the exact implementation returned by GetFactory