Add an extension point for customizing establishing of ADO.NET connections

[a-belevich]

Make usage of NHibernate compatible with SET NOCOUNT ON DB-wide setting #112 issue shows how NOCOUNT server setting can break the NHibernate persistence. It was solved by injecting NHibernate's DriverConnectionProvider, that fixes connections immediately after their opening. However, when SQL Server transport is used, and the same database is used for Timeouts persistence and SQL Transport, it can happen that connections opened for transport can be used by Timeouts persistence routines.

Solution: allow injection of custom SQL connections' factories, like NHibernate does. Such factories can, for example, send SET NOCOUNT OFF command immediately after opening the connection.

[ramonsmits]

@a-belevich Thanks for the effort! There are a couple of improvements before we can merge this.

• We do not want to expose public types when possible
• The code is using a factory. Our current code base is using the object builder and NServiceBus.NHibernate has the ability to create a custom session. Having a similar extension point for the SQL transport would make sense.

Having an API like:

public void Configure()
{
    BusConfiguration busConfiguration = new BusConfiguration();
    busConfiguration
        .UseTransport<SqlServerTransport>()
        .UseCustomConnectionCreationMethod(CreateSession);
}

static SqlConnection CreateSession(string connectionString)
{
    var conn = new SqlConnection(connectionString);
    conn.Open();
    return conn;
}

[a-belevich]

@ramonsmits Thank you for review. New version uses injection instead of static factory class. Now configuration looks like

    configuration
        .UseTransport<SqlServerTransport>()
        .UseCustomSqlConnectionFactory(NoCountSafeSqlConnectionFactory.OpenNewConnection);

where factory is of type Func<string, SqlConnection>.

@SzymonPobiega Ramon mentioned that he's going to vacation. If it's still true, could you please take a look?

[SzymonPobiega]

@a-belevich looks good. One thing that I would change is registration of Func<string, SqlConnection>. I would wrap that in a private class e.g. ConnectionFactory. The reason is, it would be more explicit in the class that use it looking just on a type what a constructor argument is for. Also, there is a chance (small but...) that registraction of a Func<string, SqlConnection> might clash with another feature wanting to register same type.

Do you have time to do this small adjustment? If no, I can do it after merging. Any way, thanks for the contribution!

[a-belevich]

@SzymonPobiega Thank you for reviewing. I've added CustomSqlConnectionFactory class that wraps the Func in container. Is that the change you've meant?

[SzymonPobiega]

@a-belevich thanks a lot! Merged.