We've recently had a problem at my employer where we were performing a very large number of database retrievals in a class called from a BizTalk Orchestration.  The class was already performing checks to ensure it only went after a particular piece of data once, but performance was still lacking compared to the desired results.  What was needed was to look for "economy of scale" solutions to this problem, because we were likely to be calling this Orchestration on multiple threads at once almost all day.

The solution?  A Singleton Pattern caching mechanism so that multiple threads would retrieve the rows in question only once and then store it in memory for a short period (the data was over a very non-dynamic nature).  The solution hinges on a very important thing for .NET developers to remember about BizTalk Server : BizTalk Server 2004 is itself a .NET application!  This means that the service which runs all of the Orchestrations creates a .NET AppDomain when it starts and a static structure (like a Singleton) will be reachable by any threads started within the AppDomain.  Once a single thread had caused the cache to contain a particular row of data, all other threads would be able to work from the copy in memory.  We saw radical increases in performance from this relatively simple change.

Disclaimer : Be certain to thread-safe your Singleton, or you will throw your entire BizTalk Server into a race condition very quickly.