views:

223

answers:

2

Suppose there are different groups of scientists (Medical) serving emergency tickets. When an emergency ticket arrives for the common pool (group), at any time only one scientist is allowed to pick up the ticket , while others can or will be notified automatically that this particular guy is working on the ticket.

note : A single guy can work on multiple tickets with different deadlines.

When the ticket is too complicated to solve, the guy who picked up the ticket can hand it over over to other in the same group or different group. In such case the reason for such hand over should be propagated immediately to others.

At an extreme need the task on single ticket can be decomposed and distributed among groups. If a task is split and shared among groups for single ticket, the guys who are sharing the tickets will not be allowed to pick up any new ticket or work on other existing ticket (doing so, he will be notified that he is working on shared ticket).


My question is:
Is Observer pattern is the best choice for notifying the service or other design pattern is available to handle it smoothly (deadlock freely).?

+2  A: 

Sounds to me like Messaging / Queueing would be a good fit

flq
Thanks Frank for giving suggestion
+2  A: 

What you need is a Queue.

Depending on how you implement it, you could use

  • System.Collections.Generic.Queue, useful for single thread enqueue or dequeue. You could also protect it with a lock for concurrent access.
  • The concurrent Queue in VS10, for multiple threads putting and getting
  • MSMQ for its queueing capabilities, especially useful when using a distributed design
  • a SQL Server database, again interesting when using a distributed design

For notifications, yes, a pub/sub mechanism is required. Again, there are options there.

Cheeso
Sure this is what i am looking for.Just I am 6 months old in programming (fresh hand).Thank you very much for serving the details.