thread-safetybiztalkbiztalk-mapperthreadstatic

BizTalk mapper and the [ThreadStatic] attribute

I've recently encountered an issue with the multi-threaded nature of the BizTalk Mapper and how it handles external assemblies.

As this quote from MSDN indicates:

Important Any code written in an external assembly for use in a scripting functoid needs to be thread safe. This is required because multiple instances of a map can use these .NET instances at run time under stress conditions.

The Mapper will reuse instances of external assemblies.

In a utility assembly my team was using we had the following code:

public class MapUtil
{
    private string _storeReference;

    public void SetStoreReference(string ref)
    {
       _storeReference = ref;
    }

    public string GetStoreReference()
    {
        return _storeReference;
    }
}

This was causing storereferences from one file to be mapped to different files.

I (appear) to have fixed this by decorating the private field with [ThreadStatic]

[ThreadStatic]
private static string _storeReference;

My question is - does anyone know of any issues with this in the BizTalk Mapper? I'm aware that there are issues using [ThreadStatic] in Asp.Net for examble, due to threads being reused, but can find no documentation on the way the BizTalk mapper deals with threads.

Solution

  • I've still not found a definitive statement along the lines of 'The threading behaviour within the BizTalk Mapper is xyz, so you should take care you use method abc' and I'm not sure that such an answer is going to come from anywhere outside the BizTalk product team.

    My one colleague with direct contacts to the product team is on extended Christmas leave (lucky dog) so until he returns I just thought I'd note that with the change made to our code we have not seen a single recurrence of the threading issues on a high volume production server.

    Well - that isn't quite true, I managed to miss the static keyword from one property on my helper class and for that property we did still see the threading issues. I'll take that as proof of ThreadStatic being the right way to go for now.