As part of a project we're working on for one of our clients, we built a transactional receive adapter for BizTalk Server 2004. The adapter itself is working just fine, and truth be told, it was far easier to write than I originally expected, which is good.

However, we have been noticing something a little odd that has me worried a bit. The adapter we built is an isolated receive adapter and what we are seeing is that everytime the isolated host for the adapter is initialized (or rather, just after initializing the adapter into the hosting process), the following error is reported by BizTalk to the application event log:

Event Type: Error
Event Source: BizTalk Server 2004
Event Category: BizTalk Server 2004
Event ID: 6912
Date: 5/20/2005
Time: 11:22:44 AM
User: N/A
The following stored procedure call failed:
" { call admsvr_ReceiveLocation_GetAllInApp( ?)}".
SQL Server returned error string: "Distributed transaction completed. Either
enlist this session in a new transaction or the NULL transaction.".

After doing a lot of digging and a lot of load testing, I've found out the following regarding the error:

  • The error is caused by the BizTalk runtime trying to refresh the configuration cache inside the adapter's isolated host (i.e. our own process), not by the BizTalk application hosts.
  • The error only appears to be triggered for the first or second configuration cache refresh after the adapter is initialized. I checked this by setting the cache refresh time to 5 seconds during load testing. Even after running for an extended period of time during high load with transactions commiting and aborting from multiple threads, the error doesn't appear to surface after that.
  • The configuration cache in the isolated host is getting refreshed correctly, I checked by changing configuration on the receive locations used during load testing and seeing the changes picked up at the next refresh cycle with no problem. I also ran a SQL Server profiler trace during testing and the Stored Procedure still gets called every five seconds with no problems.

Because of this pattern, I'm a little bit stumped as to what the cause of the problem is, and while it doesn't seem to cause any real problems, I'm not very interested in leaving the error popping around in the event log and not knowing what it is we're doing to cause it. Any ideas?

Tomas Restrepo

Software developer located in Colombia.