Hi guys,
We have ASPNet Zero solution running in two Azure App Services spread over 2 geographic locations and it works well, however both instances are running the same background jobs im guessing because the job query transaction is not blocking reading of the same rows.
So my question is can I simply implement my own background job store to lock the reading of rows (in effect making it only one instance can read any single job at a time) and fix the issue. Or is it more systemic than that and I would need to adjust other layers of the background job code?
I do want the ability for multiple instances to process jobs just not the same jobs, our project will probably end up scaling up to 3-6 instances over the coming months with one of the purposes to utilise the job system accross all of them
Thanks in advance
5 Answer(s)
-
0
I suggest you use a higher background job library, such as Hangfire.
-
0
I was going to check that out as well but still wondering if my solution above is viable?
-
0
I assume you are using the same database. If you use transaction isolation, you should be able to lock the data.
But I still recommend that you use a more advanced background job library, because you can't consider all possible situations.
-
0
I will have a look thanks
-
0
Thanks for the suggestion maliming i didnt realise that with zero hangfire is fully setup to go already i just had to toggle the variable in WebConsts and replace the service in Web Module and was up and running.
Works great, I turned the WebConsts flag into an app setting and added a setting for worker count because 20 was too CPU heavy per instance and it now works great.
Thanks for making it easy!
