We've been working on an ongoing issue with BizTalk 2006 at the office.  We've had a two fold problem with SQL Database blocking and our Messga Queues filling up with control messages.  After all of the go-arounds with Microsoft Professional Support Services (PSS), we collected enough data and they were able to reproduce the run-away queues.  They took all of this and produce a hot fix within 3 weeks.  After testing and installationin production, the blocking returned in the database.  But on the good side, the message queues did not fill up again.  So problem partially solved but the fun goes on.  The hot fix solved the problem of what happens when a cache service calls InstanceComplete.  If there is more than one message for the old instance, InstanceComplete gets called more than once causing the second call to fail because the instance had already been terminated by the previous call.  The batch operation is blown and the old caching service instance never gets properly cleaned up.  This old instance still gets control messages from the BizTalk core and since it is not actually running... they accumulate.  They accumulate alot!

So the accumulation no longer takes place... we are still concerned about the blocking.  Our port watcher application that enumerates pesky receive ports that shut down frequently.  When the port watcher calls into the WMI object model to enumerate the receive locations, ISSOConfigStore.GetConfigInfo() gets called.  This then calls ssox_spLookupXp whic reads from the SSO database and is the source of the blocking.  We are running more traces to gather information for PSS.  Stay tuned.