问题
Where I work they are using Long Polling techniques to detect events as they occur in the database. While it works...I think everyone would agree polling the database isn't optimal.
I would rather attempt some kind of push-technology or technique. As such, 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.
There are plenty of examples on how to do this:
- Call web service from SQL CLR?
- How to invoke webservice from SQL Server stored procedure
- Using Webservices and Xml Serialization in CLR Integration
However, I am a little worried about wisdom & performance of doing so.
SO MY QUESTIONS ARE:
- Can long-running trigger processes prevent the original INSERT from completing?
- Can failed trigger processes prevent the original INSERT from completing?
- Do TRIGGERS run on their own thread?
- Is this stupid to attempt or is there a better option?
回答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.
While SQLCLR would be needed to make a Web Service call, you likely wouldn't need SQLCLR to simply drop an event into a queue.
Can long-running trigger processes prevent the original INSERT from completing?
It is not an issue of "can": they absolutely will, because Triggers are part of the Transaction that is the DML statement (or DDL statement in the case of a DDL Trigger, or Log On in the case of a LOGON Trigger). As long as a Trigger is executing, the DML statement that fired it is waiting to COMMIT (this is all handled automatically).
Can failed trigger processes prevent the original INSERT from completing?
It is not an issue of "can": they absolutely will, because Triggers are part of the Transaction that is the DML statement. In fact, if you want to cancel a DML operation based on some logic, just call ROLLBACK;.
Do TRIGGERS run on their own thread?
If you are asking if they run asynchronously to the DML statement that fired them, no. As per the prior two answers above, they are part of the same Transaction. Triggers don't have anything to do until the DML statement completes the initial work -- including validation of CHECK / UNIQUE / etc Constraints -- and the DML statement can't complete until the Trigger finishes.
Is this stupid to attempt or is there a better option?
Not stupid, though doing a direct Web Service call is better suited to some situations than to others. People have certainly done this and have been successful at it, but I am sure that quite a few have also made a complete mess of things attempting to do this in situations where the conditions were not favorable. I would say that if a) the Web Service is sitting on the local intranet (i.e. no latency, or practically none), and b) the Web Service call completes quickly (or at least times out quickly enough), then you should be fine to do this.
However, given that this is going to be in a Trigger, that should be handled a bit more cautiously. Which leads me to a few "better options" that I suggested in a nearly duplicate question, over on DBA.StackExchange just 2 days ago:
Can I run a CLR Stored Procedure on a different server than the database instance?
And, the following link is another very similar question (here on S.O.) that came up just 6 days ago, regarding Web Service calls. My answer to that one has info on reducing contention between networking calls in general. That is something that you should be aware of, even if you take the queue approach and have a T-SQL Stored Procedure, kicked-off by a SQL Server Agent job, call a SQLCLR object to do the Web Service call.
SQL Server CLR Threading
来源：https://stackoverflow.com/questions/35248234/sql-clr-for-event-driven-communication