yowl wrote:
That makes sense with the meaning of word transient. It does not mean however that "it is always safe to retry this operation and carry on" which is what happens with the recovery strategy. Not a big deal as I can just exclude deadlock by extending the SqlAzureRecoveryStrategy:
public class AzureRecoveryStrategy : SqlAzureRecoveryStrategy
{
protected override bool IsTransientException(Exception toCheck)
{
// exclude deadlocks
var toCheckAsSqlException = toCheck as SqlException;
if (toCheckAsSqlException == null)
{
return false;
}
if ((from SqlError error in toCheckAsSqlException.Errors select error.Number).Any(number => number == 1205))
{
return false;
}
return base.IsTransientException(toCheck);
}
}
I've not tried what happens with timeout, which is safe to retry, on the action procedures, I guess it will fail in the same way if used with a recovery strategy on the adapter. I'll create a test when I have time.
Good point. I must say I have no opinion in this, the list was more or less a starting point and it might indeed very well be the list of errors detected today are in some contexts too broad and less errors should be detected at some points in the application.
With transaction scope it's a bit vague as well, as normally when an exception occurs the transaction rolls back and then is retried if the strategy allows it, but a transaction scope is cross-adapter in theory, so you have sub-transactions in play. I think it's hard to determine which errors might be allowed at these situations, as excluding some of them by default might hurt users who use an ado.net transaction (as that transaction is retried from the start on an error).
Proc calls are also a grey area, as a proc might call whatever it likes, e.g. unmanaged code, extended procs, and these actions might not be retryable, e.g. sending an email.
Not sure if this is a satisfying answer, I'm a bit undecided what to do, as there's no clear 'it's wrong, this has to change into that' scenario, it's very bound to the context the strategy is used in, IMHO.