SqlServer Instant Re-Queue implementation may be problematic


I’ve had a look into the new solution for ‘Instant Re-Queue’ and think there are situations which don’t work very well with this approach.
The reason for potential problems is that hangfire now opens a new sql session and a new transaction when Dequeue is called and only calls commit / rollback (and returns the connection) when the job either finished or failed.
This is especially problematic for long-running jobs which will keep a transaction open for a long time (this prevents the db transaction log from being truncated and may therefore lead to ‘out of log space’ conditions).
Also, having lots of open db connections might hurt performance as db connections are quite expensive (which is why they’re usually pooled).

Have you considered letting the application choose if the jobs should be blocked by status (like before 1.5.0) or by db transaction (like 1.5.0 and later)? Another approach would be to distinguish between long-running and short-running jobs and use different locking strategies.

Thanks for your help and cheers to hangfire

Having a separate DB for hangfire solved the issue to an extent of no worries. Its very smooth now. Having said that, it is best to go with msmq or redis etc. storage for best performance.

Please visit the SO thread for more details.