Semaphores vs. Singleton in order to manage limited resources in BizTalk

Everybody needs semaphores. In the last couple of months I myself encounter 3 times the need to use semaphores.

Since my primary job is BizTalk – I need a semaphore solution for BTS.

Searching the net for open source semaphore solution results with such solutions, but (the best I found) limited to the current server running the application.

Since my production environment of BizTalk servers holding more than one server, these solutions don't work for me.

BizTalk has an option to use singleton as a mechanism to control resources. This is how to do it using singleton:

• Create orchestration A (Main) to handle the process
  
  • When need to use the limited resource do that
    
    • Send a message using direct binding to orchestration B
      
    • Receive response message from orchestration B
      
  • Continue the business process required in
    
• Create orchestration B
  
  • Create a correlation set that will be used to identify the similarity between the messages arrives to this orchestration to make it unique BizTalk.
    
  • Receive the request from orchestration A and initial the correlation set.
    
  • Do the resource limited operation
    
  • Create a loop
    
    • Add a listen shape
      
      • On one hand Receive another message
        
      • On second hand add a timeout
        
    • If timeout occurred exist loop, and leave orchestration
      
    • If message received handle (again) the limited resource operation
      

(Detailed instructions can be found here: http://aspalliance.com/1208_Singleton_Orchestration_in_BizTalk_Server.3)

Here is a picture of orchestration demonstrating this solution:

Challenges when using this way:

1. Unable to limit the number of resources in case the number of resources is larger than 1.
   
2. There is no easy way to trace direct binding ports, and therefore to debug errors in the mechanism.
   
3. There is no accurate time to leave the singleton orchestration (how much time to set in the timeout hand).
   
4. It might cause a zombies message (although it pretty rear) when a message coming to the MessageBox after timeout event already fired and orchestration still did not complete termination.
   

We found out a different way to handle the limited resource problem and to offer a solution for it.

How about using an adapter to get a semaphore?

In this way the solution is very simple.

Once configure the adapter, many resources can be managed, and number of items per resource can be defined.

Construct a message including the semaphore name and number of resource items need to be obtained (not only 1, but 1 is the default), and send a message to the adapter to get the semaphore. After getting it do the business process required the resource and then release the resource by sending the same message again to the adapter.

The next picture demonstrates the same operation using the semaphore adapter.

Shimshon Fishler