Looking ahead, to when a Web Farm will be created...
We have various windows service applications performing various back-ground tasks: sending emails, thumbnailing/processing files etc.
In a server farm environment, we could in theory install and run each service on each machine, however there may be conflicts due to business object based "first-write-win" or undesirable duplication of tasks eg: the same emails being send a number of times.
The "first-write-wins" scenario can be overcome through code or logic that resolves the issue or skips the item. (if its a basic queuing mechanism (query list and process record) it will just be tried again)
For the duplication of tasks, one could perform tasks in transactions to prevent other processses grabbing the same resources, however I guess they will just wait and we would need to handle some login based on things happening again? Would this be the case?
To prevent duplication of tasks I am thinking of maybe building some mechanism that writes a "locking flag" to the database that will be set by the first service that fires up. This flag will be dated and reference the instance of the service. The service that "owns" the flag will run the tasks and periodically update this date. There will also be a timeout/tolerance setting on each service in the situation where the service doesnt own the flag, it will check the tolerance and take over if required.
Does this sound like a resonable solution or should one go to a better message queuing based solution at that stage (also not sure how that would work in a farm environement?
Tecnologies: C# / ASP.NET / SQL Server