用于事件驱动通信的SQL CLR
在我工作的地方，他们使用长轮询技术来检测数据库中发生的事件。 虽然它有效…我想每个人都会同意轮询数据库不是最佳的。
我宁愿尝试某种推送技术或技术。 因此，我正在考虑使用表触发器来调用SQL CLR对象，该对象将事件放入队列或调用Web服务。
有很多关于如何做到这一点的例子：
- 从SQL CLR调用Web服务？
- 如何从SQL Server存储过程调用Web服务
- 在CLR集成中使用Webservices和Xml序列化
但是，我有点担心这样做的智慧和表现。
所以我的问题是：
- 长时间运行的触发器进程是否可以阻止原始INSERT完成？
- 失败的触发器进程是否会阻止原始INSERT完成？
- TRIGGERS是否在他们自己的线程上运行？
- 这是愚蠢的尝试还是有更好的选择？
我正在考虑使用表触发器来调用SQL CLR对象，该对象将事件放入队列或调用Web服务。
虽然需要SQLCLR来进行Web服务调用，但您可能不需要SQLCLR来简单地将事件放入队列中。
长时间运行的触发器进程是否可以阻止原始INSERT完成？
这不是“可以”的问题：它们绝对会，因为触发器是事务的一部分，即DML语句（或DDL触发器时的DDL语句，或者LOGON触发器时的登录）。 只要触发器正在执行，触发它的DML语句就等待COMMIT（这都是自动处理的）。
失败的触发器进程是否会阻止原始INSERT完成？
它不是“可以”的问题：它们绝对会，因为触发器是事务的一部分，即DML语句。 实际上，如果你想根据某些逻辑取消DML操作，只需调用ROLLBACK; 。
TRIGGERS是否在他们自己的线程上运行？
如果您询问它们是否与触发它们的DML语句异步运行，请执行。 根据上述前两个答案，它们是同一交易的一部分。 在DML语句完成初始工作之前，触发器没有任何操作 – 包括CHECK / UNIQUE / etc约束的validation – 并且在触发器完成之前DML语句无法完成。
这是愚蠢的尝试还是有更好的选择？
虽然做一个直接的Web服务调用更适合某些情况而不是其他情况，但这并不愚蠢。 人们当然已经做到了这一点，并且已经取得了成功，但我确信在条件不利的情况下，有不少人也试图做到这一点。 我会说，如果a）Web服务正在本地内部网上（即没有延迟，或几乎没有），并且b）Web服务调用快速完成（或者至少足够快地完成），那么你应该没问题去做这个。
但是，鉴于这将是一个触发器，应该谨慎处理。 这让我想到了一些“更好的选择”，我在一个几乎重复的问题中建议，仅在2天前在DBA.StackExchange上：
我可以在与数据库实例不同的服务器上运行CLR存储过程吗？
而且，以下链接是另一个非常相似的问题（此处为SO），该问题仅在6天前出现，涉及Web服务调用。 我对这个问题的回答有关于减少网络通话之间争用的信息。 这是你应该注意的事情，即使你采用队列方法并拥有一个由SQL Server代理作业启动的T-SQL存储过程，也可以调用SQLCLR对象来进行Web服务调用。
SQL Server CLR线程