Two Servers, One DB and Autofac

I’ve spent the last couple of days trying to get two servers which use different Autofac containers to use a shared database, and finally decided that it just doesn’t work at all.

I had 1 server running fine already, using background and recurring jobs successfully. It is configured with an Autofac container and was working fine. It’s part of an MVC application so I also had the dashboard here. It also worked fine.

I needed to add support for scheduled background jobs to the WebAPI site, related to this MVC site. I added Hangfire and pointed it at the same DB. I added a second server, with a different autofac container, containing different objects / interfaces and that’s where it started going badly.
I needed the jobs scheduled by the newserver to be run on the newserver.

Even if I separated the servers with queues (original server was “default” only, new server was “newserver” only) and scheduled jobs from “newserver” on the “newserver” queue, it would appear that only the original server was being used to run the jobs…Or at least only the “original” autofac container was being used to resolve my objects / methods. I kept getting "“Cannot find the target method” displayed in the Dashboard, then the scheduled job would fail to enqueue.

The only way I’ve managed to get it working is by not including a background server in the webAPI site, and just scheduling jobs with it instead…Then all jobs are being run on the original server, which means I’ve had to move all of the code that was in the API project into a shared project which is now also used by the MVC project, and registered in the MVC project’s Autofac container…Not ideal, but it does work.

Does anyone have a sample solution showing two web projects (MVC,WebAPI) sharing a hangfire database, using autofac with different containers in each ?!
Has anyone else tried it, even?

Use different databases for different code bases, or use a shared assembly that contains all the required interfaces. Queues do not provide proper isolation yet due to early architectural decisions. This behavior will be changed in Hangfire 2.0, allowing microservices work fine. But currently there’s no silver bullet to make this work.

When I was writing my post, it occurred to me that the solution would be to separate out Hangfire into it’s own website/service which just ran hangfire jobs, with a dashboard, but have the ability to create jobs in both the MVC and webAPI sites (and no dashboard or job processing in either site)

Sounds like Queues and IoC don’t really work well together.