SQL Server 项目的进程间通信答案

【问题标题】：Interprocess communication from SQL Server ProjectSQL Server 项目的进程间通信
【发布时间】：2010-12-13 23:54:46
【问题描述】：

我正在尝试创建一个 SQL Server CLR 用户定义函数，该函数连接到第 3 方服务（托管在与 SQL Server 实例相同的服务器上）。有没有办法让 WCF 命名管道或 TCP 在这种情况下工作？如果我提供中介服务，有没有更好的方法来做到这一点？

【问题讨论】：

【解决方案1】：

不要在 SQLCLR 中实现 IPC。托管 CLR 的 SQL 服务器使用 SQL threading primitives，您最终会饿死 SQL 工作线程和调度程序。

从 SQL Server 之外的进程执行所有 IPC。如果您需要通过 SQL 作业（来自存储过程和触发器）与此进程通信，请使用数据库内队列，通过Tables as Queues 或Service Broker。

【讨论】：

为什么 IPC 会比 SQLCLR 的任何其他用途更糟糕？
因为它使当前进程（sqlservr.exe）阻塞等待其他进程响应。由于 SQL 是一个协作的用户模式多线程环境，这些外部块会停止所有 SQL 处理。
所以这是IPC花费时间的问题？
主要是因为涉及 IPC 时故障的不可预测性。我见过的 SQLCLR+IPC 的每一种组合（我也见过一些）在即使是轻微负载的情况下也会导致生产中的崩溃灾难。加起来的因素太复杂了，无法在这里描述，它们涉及 SQL 线程的性质、在 SQL 调度程序和 CLR 托管线程中的抢占式，而且我认为我不知道所有所涉及的交互，但我足够了解，可以提出非常强烈的建议来避免这种情况。要点是服务器最终导致所有工作人员被盗并在 CLR 等待事件中被阻止。
@AlekDavis：afaik XP 以抢占模式执行。 SQLCLR 在协作模式下执行，至少在他们调用BeginThreadAffinity() 之前。抢先模式修复了一些问题，因此 XP 更好一些。但是，如果您可以从 XP 中避免 IPC，请避免使用它。如果您从触发器执行 IPC，请考虑使用消息队列，从触发器插入队列并让外部进程处理 IPC，在触发器 xact 提交之后。