IN SQL Server является CLR Threadsafe

Question

У меня есть интерфейс в CLR между SQL Server и веб-службами Exchange для синхронизации и отправки сообщений электронной почты между приложениями. При тестировании это работает (ред) без каких-либо проблем; мы наблюдаем спорадические проблемы в производственной среде, где более длинные задачи веб-службы, по-видимому, перекрываются.

Мой вопрос очень прост, и я не могу решить, прочитав подробности CLR на MSDN - является ли CLR Thread Safe или нет «из коробки».

Если нет, то лучший способ сделать звонки в CLR потокобезопасными - это заблокировать мои процедуры или есть менее радикальная альтернатива.

---

Спасибо за ваши ответы; мы подходим к этой проблеме EWS / Impersonation, а не к проблеме SQL. Мы провели новый набор нагрузочных тестов в нерабочее время в системе и даже при большой нагрузке (в 1000 раз выше, чем приложение до сих пор) мы не можем видеть проблему утечки памяти / многопоточности, поэтому мы сейчас смотрим в другом месте ..

Answer 1

Не используйте in-proc CLR для внешнего подключения, к веб-сервисам, обмену и т. Д.Используйте обычный процесс вне SQL Server.Вы увидите больше, чем просто «спорадические» проблемы: вы исчерпаете рабочий пул для событий CLR, и SQL Server заморозит .

Answer 2

Ответ на самом деле зависит от того, как вы пишете свой .Net код и как вы регистрируете свою сборку. По умолчанию и по общему предпочтению сборки SQLCLR создаются как SAFE, что означает, что SQL Server сканирует сборку при ее создании (фактическая инструкция CREATE ASSEMBLY), чтобы определить, соответствует ли она правилам сборки SAFE. БЕЗОПАСНАЯ сборка не имеет переменных экземпляра не только для чтения. Это означает, что все переменные являются переменными экземпляра, и если вы объявляете статическую переменную, вы должны использовать модификатор «только для чтения». Это гарантирует, что вы не делитесь данными между потоками.

ОДНАКО, вы можете создать статическую переменную в классе и изменить ее, но сборка должна быть создана как UNSAFE. Попытка создать его как SAFE приведет к следующей ошибке:

Не удалось создать CREATE ASSEMBLY, поскольку метод «MethodName» типа «ClassName» в безопасной сборке «AssemblyName» сохраняет статическое поле. Хранение в статическом поле недопустимо в безопасных сборках.

Хранение в статической переменной не является потокобезопасным, и, следовательно, вы должны дать сборке разрешение UNSAFE. Но вне этого случая SQLCLR является потокобезопасным.

Answer 3

Проведя много независимых тестов на CLR сейчас (намеренно пытаясь заставить его потерпеть неудачу), если ваш код CLR написан правильно - аккуратно объявляйте переменные со значениями инициализации, кажется, что CLR является потокобезопасным.

Answer 4

Основная проблема, которую вы видите с кодом SQL CLR, - это нехватка памяти, что приводит к сбросу AppDomain.Это эквивалентно краху ОС с точки зрения вашего кода.При использовании SQLCLR вы используете отдельный пул памяти, управляемый SQL Server, который намного меньше и менее гибок, чем вы привыкли.Мне сказали, что команда SQLCLR работает над этой проблемой.

Одно важное замечание: если вы получите сброс SQLCLR AppDomain, стабильность вашего сервера в других отношениях не должна пострадать.Сбой процедуры SQLCLR просто возвращает ошибку TSQL вызывающей стороне.