I have a question that’s going to sound really dubious:
I am implementing hangfire in a multi tier environment where the backend tier is separated from the frontend tier by means of a service framework. In this solution, the backend tier hosts logic and processes. We use hangfire for recurring processes, as well over long interval (monthly; payment, prolonging contracts etc.) as more short-lived (hourly or minutely even, like cleaning caches and rebuilding read-optimised data graphs). Hangfire jobs kick off in a wrapper that takes care of application-specific contexting, notifications, etc. and will make use of logic classes.
Now the thing: to use the logic classes, initialisation routines are being kicked off for the registering of factory methods and some other dependencies. In this routine, however, there is a call to a method that starts the hangfire server by calling the bare-metal BackgroundJobServer (namely, this is a logic-regulated task). This is necessary because we run outside an owin context.
My question: when a background task kicks off and fires the initialisation routine, will a new service instance spawn and “take hostage” the thread/task/job, or is there some intelligence built-in to the hangfire server that cuts off this behaviour? If not, how would I go and create this safely? I can imagine some really nasty scenario’s already if this behaviour thrives in runtime.
A quick answer would be something like “then fire off all except the job server creation”. This would create a hard dependency between de scheduling library, which builds on hangfire, and the logic classes. The current dependency is the other way around, and I would prefer to keep it that way.
I feel like there is a much more simple solution than the one I’m trying to hack my way around here. A different approach is a welcome answer as well, but the preferred solution is one where the background job server will know when not to become active.
Thanks a lot already,