¿Cómo implementar el marco de manejo de fallas transitorias de SQL Azure para Dapper?

azure-sql-database dapper

Pregunta

Soy un chico de vb.net y tengo dificultades para leer C #. Recopilé el C # Dapper en una DLL y lo uso mi aplicación. Mi principal preocupación es que creo que necesito modificar la fuente para integrar de manera predeterminada el Marco de manejo de fallas transitorias para SQL Azure en cada consulta SQL.

Puedo agregar la lógica de reintento en el nivel de conexión porque está encima de dapper, pero no en el nivel de consulta de ejecución que está incrustado en la clase drapper.

¿Alguien ha hecho eso todavía?

* ACTUALIZACIÓN *

¿Usar solo ReliableSqlConnection en la parte superior de la llamada de Dapper manejará una lógica de reintento en la ejecución de no consulta?

Aquí hay un ejemplo de código de reintento de MS con el fallo de transietn

using Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling;
using Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.AzureStorage;
using Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.SqlAzure;
using System.Data;

...

using (ReliableSqlConnection conn = new ReliableSqlConnection(connString, retryPolicy))
{
conn.Open();

IDbCommand selectCommand = conn.CreateCommand();
selectCommand.CommandText = 
  "UPDATE Application SET [DateUpdated] = getdate()";

// Execute the above query using a retry-aware ExecuteCommand method which 
// will automatically retry if the query has failed (or connection was 
// dropped).
int recordsAffected = conn.ExecuteCommand(selectCommand, retryPolicy);

}

Aquí está la parte de ejecución del código Dapper, se usa el mismo nombre pero supongo que es una función de ejecución personalizada

    private static int ExecuteCommand(IDbConnection cnn, IDbTransaction transaction, string sql, Action<IDbCommand, object> paramReader, object obj, int? commandTimeout, CommandType? commandType)
    {
        IDbCommand cmd = null;
        bool wasClosed = cnn.State == ConnectionState.Closed;
        try
        {
            cmd = SetupCommand(cnn, transaction, sql, paramReader, obj, commandTimeout, commandType);
            if (wasClosed) cnn.Open();
            return cmd.ExecuteNonQuery();
        }
        finally
        {
            if (wasClosed) cnn.Close();
            if (cmd != null) cmd.Dispose();
        }
    }

Respuesta popular

Recomiendo encapsular el reintento alrededor de Dapper, preferentemente utilizando el método RetryPolicy.ExecuteAction. De esta forma, tanto la llamada ABIERTA a la conexión como el comando mismo se reintentarán utilizando la política de reintento de TFH:

Por ejemplo:

        SqlRetryPolicy.ExecuteAction(() =>
        {
            // Place Dapper ExecuteCommand here: e.g.
            ExecuteCommand(conn,  trans, ... )
        });


Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow