BizTalk mapper и атрибут [ThreadStatic]

Question

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

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

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

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

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

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?Я знаю, что есть проблемы с использованием [ThreadStatic] в Asp.Net например, из-за повторного использования потоков, но не могу найти документации о том, как BizTalk mapper работает с потоками.

Answer 1

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

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

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

Answer 2

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