Сопоставитель BizTalk и атрибут [ThreadStatic]

Question

Недавно я столкнулся с проблемой многопоточной природы BizTalk Mapper и того, как он обрабатывает внешние сборки.

Как указывает эта цитата из MSDN:

Важно Любой код, написанный на внешняя сборка для использования в скриптовый функтоид должен быть потоком безопасный. Это необходимо, потому что несколько экземпляров карты могут использовать эти экземпляры .NET во время выполнения под стрессовые условия.

Mapper будет повторно использовать экземпляры внешних сборок.

В сборке утилит, которую использовала моя команда, у нас был следующий код:

public class MapUtil
{
    private string _storeReference;

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

    public string GetStoreReference()
    {
        return _storeReference;
    }
}

Это приводило к привязке ссылок магазина из одного файла к другим файлам.

Я (кажется) исправил это, украсив личное поле [ThreadStatic]

[ThreadStatic]
private static string _storeReference;

Мой вопрос: кто-нибудь знает о каких-либо проблемах с этим в BizTalk Mapper? Мне известно, что в Asp.Net существуют проблемы с использованием [ThreadStatic] из-за повторного использования потоков, но я не могу найти документацию о том, как картограф BizTalk работает с потоками.

Answer 1

Я использовал ThreadStatic, чтобы установить переменную пользовательского конвейера приема, а затем получить доступ к ее значению в BizTalk Map (через вспомогательный класс). до сих пор не было никаких проблем - проверено с ~ 50 параллельными вызовами.

Answer 2

Я до сих пор не нашел однозначного утверждения в духе «Потоки в BizTalk Mapper - это xyz, поэтому вам следует позаботиться о том, чтобы вы использовали метод abc», и я не уверен, что такой ответ будет Приходите из любого места за пределами команды разработчиков BizTalk.

Мой единственный коллега, имеющий прямые контакты с командой разработчиков, находится в длительном рождественском отпуске (счастливчик), поэтому, пока он не вернется, я просто подумал, что отмечу, что с внесенными в наш код изменениями мы не увидели ни одного повторения проблемы с многопоточностью на производственном сервере большого объема.

Что ж, это не совсем так, мне удалось пропустить ключевое слово static из одного свойства моего вспомогательного класса, и для этого свойства мы все еще видели проблемы с многопоточностью. Я приму это как доказательство того, что ThreadStatic - правильный путь.