Publisher subscriber solves this?
Suppose there are different groups of scientists (medical) serving emergency tickets. When an emergency ticket arrives at the general pool (group), only one scientist is allowed to pick up the ticket at any time , while others may or will be automatically notified that this particular guy is working on a ticket.
Note. One guy can work with several tickets with different terms.
When the ticket is too difficult to deal with, the guy who took the ticket can give it to someone else in the same group or a different group. In such a case, the reason for such a transfer should immediately be extended to others.
As a last resort, the single ticket problem can be decomposed and distributed among the groups. If the task is split and split among the groups for a single ticket, the guys who split the tickets will not be allowed to pick up a new ticket or work on another existing ticket (while being told that they are working on a shared ticket).
My question is:
Is the Observer pattern the best choice for service notification or another design pattern that can be easily handled (deadlock).
source to share
You need a queue.
Depending on how you implement it, you can use
- System.Collections.Generic.Queue , useful for single queue or queue deletion. You can also protect it by locking it for simultaneous access.
- Parallel queue in VS10 , for multi-threaded input and receive
- MSMQ for its queuing capabilities, especially useful when using distributed design
- SQL Server database interesting again when using distributed design
For notifications, yes, a pub / sub mechanism is needed. Again, there are options.
- System.Event provides a base pub / additional mechanism for use within a single process.
- you can build larger pub / subsystems for WCF based distributed use.
source to share