c# - 用于事件驱动通信的 SQL CLR

Question

在我工作的地方，他们使用长轮询 技术来检测数据库中发生的事件。虽然它有效……我认为每个人都会同意轮询数据库不是最佳选择。

我宁愿尝试某种推送技术或技巧。因此，我正在考虑使用 表触发器 来调用 SQL CLR 对象，该对象要么将事件放入队列中，要么调用 Web 服务。

有很多关于如何做到这一点的例子:

• Call web service from SQL CLR?
• How to invoke webservice from SQL Server stored procedure
• Using Webservices and Xml Serialization in CLR Integration

但是，我有点担心这样做的智慧和性能。

我的问题是:

• 长时间运行的触发器进程是否会阻止原始 INSERT 完成？
• 失败的触发器进程是否会阻止原始 INSERT 完成？
• TRIGGERS 是否在自己的线程上运行？
• 这种尝试是愚蠢的还是有更好的选择？

Answer 1

I was thinking about using a table trigger to call a SQL CLR object that either drops the event into a queue or calls a web service.

虽然需要 SQLCLR 来进行 Web 服务调用，但您可能不需要 SQLCLR 来简单地将事件放入队列。

Can long-running trigger processes prevent the original INSERT from completing?

这不是“可以”的问题:他们绝对会，因为触发器是事务的一部分，它是 DML 语句(或 DDL 触发器中的 DDL 语句，或 LOGON 中的登录扳机)。只要触发器正在执行，触发它的 DML 语句就会等待提交(这一切都是自动处理的)。

Can failed trigger processes prevent the original INSERT from completing?

这不是“可以”的问题:他们绝对会，因为触发器是作为 DML 语句的事务的一部分。事实上，如果你想根据某种逻辑取消一个DML操作，只需要调用ROLLBACK;即可。

Do TRIGGERS run on their own thread?

如果您问它们是否与触发它们的 DML 语句异步运行，答案是不。根据上面的前两个答案，它们是同一交易的一部分。在 DML 语句完成初始工作(包括 CHECK/UNIQUE/等约束的验证)之前，触发器无事可做，并且在触发器完成之前，DML 语句无法完成。

Is this stupid to attempt or is there a better option?

并不愚蠢，尽管直接进行 Web 服务调用比其他情况更适合某些情况。人们当然已经这样做了并且已经成功了，但是我相信相当多的人也会在条件不利的情况下试图这样做而把事情弄得一团糟。我会说，如果 a) Web 服务位于本地 Intranet 上(即没有延迟，或者几乎没有延迟)，并且 b) Web 服务调用快速完成(或者至少超时足够快)，那么你应该没问题做这个。

但是，考虑到这将在触发器中，应该更加谨慎地处理。这让我想到了一些“更好的选择”，我在 2 天前在 DBA.StackExchange 上的一个几乎重复的问题中提出了建议:

Can I run a CLR Stored Procedure on a different server than the database instance?

并且，以下链接是 6 天前出现的另一个非常相似的问题(此处为 S.O.)，关于 Web 服务调用。我对那个问题的回答有关于减少一般网络调用之间争用的信息。这是您应该注意的事情，即使您采用队列方法并拥有由 SQL Server 代理作业启动的 T-SQL 存储过程，调用 SQLCLR 对象来执行 Web 服务调用。

SQL Server CLR Threading