This release contains important improvements when SQL Server is used as a job storage. Distributed locks are much more robust now even when there are significant connectivity issues (like those sometimes happen in Azure or other cloud environments) and require much fewer connections to SQL Server. Another improvement is related to a new option that allows transactions to be committed with fewer round-trips.

This new option is called SqlServerStorageOptions.CommandBatchMaxTimeout, is disabled by default currently and works only on .NET Framework. It uses the internal SqlCommandSet class (not available in .NET Core) to queue commands on a client and flush them within a one network call, instead of waiting for confirmation after each command. This method significantly reduces the time required for a transaction to be committed, and decrease wait time for other transactions blocked by the former one. You can enable the new mode in the following way:

GlobalConfiguration.Configuration.UseSqlServerStorage(
    "connection_string", 
    new SqlServerStorageOptions { CommandBatchMaxTimeout = TimeSpan.FromMinutes(5) });

The maximum timeout is applied when there are a lot of commands in a transaction, and should be high enough to allow SQL Server to process all the commands. Huge workloads should use higher value, but if you are processing relatively low amount of background jobs, 1 minute value should be enough.

Hangfire.SqlServer

• Added – SqlServerStorageOptions.CommandBatchMaxTimeout parameter to enable batching in transactions.
• Fixed – Timeout exceptions when there are a lot of large concurrent transactions by using the new batching method.
• Fixed – Distributed locks are safe now even in very unreliable networks and after network blips.
• Performance – Greatly decreased the number of connections required to process background jobs.
• Performance – Significantly decrease the number of round-trips required to commit a transaction.