Сообщение Использование RetryPolicy от 10.11.2017 17:56
Изменено 26.11.2017 7:58 AK107
Async bug in RetryPolicy/RetryPolicyBase.cs
еще добавлю два момента:
1. в ShouldRetryOn часто важно знать attempt, а взять его неоткуда, т.к. текущее исключение добавляется в ExceptionsEncountered уже после вызова ShouldRetryOn
2. очень важно уметь в ShoudRetryOn/GetNextDelay различать ошибки вызванные connection.Open и command.Execute, т.к. от этого напрямую зависит логика/необходимость повторов, например для оракула:
2.1 connection timeout, session killed, все ошибки listener, ORA-12570 и т.п. — нужно повторять только во время connection.Open и бессмысленно во время command.Execute, т.к. тут поможет только полный реконнект.
2.2 в то же время ORA-04068, ORA-06550 — т.е. ошибки перекомпиленных/разваленных объектов БД вполне повторять можно в command.Execute.
с другой стороны непонятно как "кто" будет повторять логику переподключения, если session killed словили в command.Execute
поэтому DataConnection.RetryPolicy использую только для "софтовых" (2.2) ошибок, а для ошибок связанных с коннектом (2.1) приходится использовать Polly.
или я все неправильно "готовлю" и все задумывалось иначе и надо по-другому?
1. в ShouldRetryOn часто важно знать attempt, а взять его неоткуда, т.к. текущее исключение добавляется в ExceptionsEncountered уже после вызова ShouldRetryOn
2. очень важно уметь в ShoudRetryOn/GetNextDelay различать ошибки вызванные connection.Open и command.Execute, т.к. от этого напрямую зависит логика/необходимость повторов, например для оракула:
2.1 connection timeout, session killed, все ошибки listener, ORA-12570 и т.п. — нужно повторять только во время connection.Open и бессмысленно во время command.Execute, т.к. тут поможет только полный реконнект.
2.2 в то же время ORA-04068, ORA-06550 — т.е. ошибки перекомпиленных/разваленных объектов БД вполне повторять можно в command.Execute.
с другой стороны непонятно как "кто" будет повторять логику переподключения, если session killed словили в command.Execute
поэтому DataConnection.RetryPolicy использую только для "софтовых" (2.2) ошибок, а для ошибок связанных с коннектом (2.1) приходится использовать Polly.
или я все неправильно "готовлю" и все задумывалось иначе и надо по-другому?
Использование RetryPolicy
еще добавлю два момента:
1. в ShouldRetryOn часто важно знать attempt, а взять его неоткуда, т.к. текущее исключение добавляется в ExceptionsEncountered уже после вызова ShouldRetryOn
2. очень важно уметь в ShoudRetryOn/GetNextDelay различать ошибки вызванные connection.Open и command.Execute, т.к. от этого напрямую зависит логика/необходимость повторов, например для оракула:
2.1 connection timeout, session killed, все ошибки listener, ORA-12570 и т.п. — нужно повторять только во время connection.Open и бессмысленно во время command.Execute, т.к. тут поможет только полный реконнект.
2.2 в то же время ORA-04068, ORA-06550 — т.е. ошибки перекомпиленных/разваленных объектов БД вполне повторять можно в command.Execute.
с другой стороны непонятно как "кто" будет повторять логику переподключения, если session killed словили в command.Execute
поэтому DataConnection.RetryPolicy использую только для "софтовых" (2.2) ошибок, а для ошибок связанных с коннектом (2.1) приходится использовать Polly.
или я все неправильно "готовлю" и все задумывалось иначе и надо по-другому?
1. в ShouldRetryOn часто важно знать attempt, а взять его неоткуда, т.к. текущее исключение добавляется в ExceptionsEncountered уже после вызова ShouldRetryOn
2. очень важно уметь в ShoudRetryOn/GetNextDelay различать ошибки вызванные connection.Open и command.Execute, т.к. от этого напрямую зависит логика/необходимость повторов, например для оракула:
2.1 connection timeout, session killed, все ошибки listener, ORA-12570 и т.п. — нужно повторять только во время connection.Open и бессмысленно во время command.Execute, т.к. тут поможет только полный реконнект.
2.2 в то же время ORA-04068, ORA-06550 — т.е. ошибки перекомпиленных/разваленных объектов БД вполне повторять можно в command.Execute.
с другой стороны непонятно как "кто" будет повторять логику переподключения, если session killed словили в command.Execute
поэтому DataConnection.RetryPolicy использую только для "софтовых" (2.2) ошибок, а для ошибок связанных с коннектом (2.1) приходится использовать Polly.
или я все неправильно "готовлю" и все задумывалось иначе и надо по-другому?