This is pretty internal stuffs – you will almost never use it yourself (you technically can, but there is no guarantee of backward compatibility whatsoever). I learned the stuff recently and found it interesting enough to share.
No matter how powerful your server(s) are, and how reliable SQL Server is, there are chances that a query can result in error. Hell, there are bunches of error codes that can be returned (and I never remember one, Google made a pretty bad habit of forgetting everything). But they can be divided into two categories:
- The un-retry-able errors, such as a grammar error in your stored procedure, or a parameter is missing, or mismatch. These errors need human-interaction to correct them before continuing.
- The retry-able errors, which means if you re-run the query, there is a chance that it would eventually succeed. Compared to the un-retry-able errors, these are in smaller number. A deadlock can be considered as retry-able (with the hope that the deadlock conditions are no longer present, the other threads finished their works and released the locks). A timeout error can be considered as retry-able (with the hope that the server can run the query faster, this time). In the end, your query can succeed, after some tries.
You might ask, why retry? The question is, why not? Retrying the query can make it works, and as it’s transparent from end-users perspective, it might provide a smoother experience for them. Say, they are trying to place an order. Because of your highly successful campaign, there are a lot of customers trying to do the same thing at the same time, resulting in some occasionally deadlocks. You’ll be much happy to silently retry and have another order in place, than showing “Something went wrong” to the customers. Of course, the previous errors will still be logged for further analytic, but you’re good for now.
Continue reading “Understand the retry policies in Episerver”
