Is there a way in SQL Server 2008 R2 to cause a timeout for a database modification involving a transaction? We have a scenario where our application code hangs or throws an exception and fails to perform a rollback or commit. This then causes other sessions to hang waiting for the transaction to complete.
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
I'm answering this with hesitation as there isn't enough information in your description of the problem to be 100% sure this is the best advice. "Hangs or throws an exception" suggests the source of the issue isn't properly understood, so proceed with caution.
The simplest solution to this is probably
The "gotcha" side-effect of the default setting is that a timeout can cause exactly the same problem, an open transaction that is the clients responsibility to handle and rollback. If the client doesn't try/catch/rollback, the transaction will remain open until attended to with (and I quote @gbn) the ultra-violence of
Edit (following comment): To identify open transactions, sp_whoisactive is probably the most feature complete.
Extending Mark's answer...
When a client timeout event occurs (.net CommandTimeout for example), the client sends an "ABORT" to SQL Server. SQL Server then simply abandons the query processing. No transaction is rolled back, no locks are released.
Now, the connection is returned to the connection pool, so it isn't closed on SQL Server. If this ever happens (via KILL or client reboot etc) then the transactions+locks will be cleared. Note that sp_reset_connection won't or doesn't clear them, even though it is advertised to do so
This detritus from the abort will block other processes.
The way to make SQL Server clear transactions+locks on client timeout (strictly, ABORT events) is to use SET XACT_ABORT ON.
You can verify this be opening 2 query windows in SSMS:
In menu Query..Query Options set a timeout of 5 seconds then run this
Window 2, this will wait forever (or hit your timeout)
SET XACT_ABORT ON has interesting side effects too:
The combination of this means that you can't use SAVEPOINTS (although, I can't recall exact behaviour) for partial commits/rollbacks. Which suits me
SO links on SET XACT_ABORT:
On nested stored procs: