En la versión 5.0.0.48 se añade una política de reintentos en la ejecución de los procedimientos almacenados de la base de datos asociada por la cuál, en caso de desencadenarse un error de interbloqueo, se volverá a lanzar la ejecución del mismo procedimiento almacenado antes de dar el error final al usuario.
Puesto que los errores de interbloqueo son generados por problemas en la concurrencia al servidor de base de datos, normalmente a causa del estrés del mismo (falta de recursos en la máquina, servidor SQL Server saturado, etc), no tiene mucho sentido abortar la ejecución del proceso y mostrar un error técnico al usuario sin antes intentar la ejecución de la misma tarea.
En este contexto, se han añadido dos nuevos parámetros al fichero de configuración de la API (appsettings.json) para controlar tanto el número de reintentos de los procesos que dan interbloqueo, como el tiempo entre dichos reintentos.
Los valores por defectos son 2 reintentos y 1 segundo entre reintentos (1000 ms). Esto supondrá que, dado un error de interbloqueo, se lanzará la ejecución del mismo proceso una segunda vez al segundo de recibir el error desde la base de datos.
En entornos con mucha carga o recursos limitados es probable que se deba modificar estos valores para adaptarlos a más ejecuciones o más tiempo entre ejecuciones, de manera que se minimice totalmente los errores obtenidos de tipo interbloqueo.
Sin embargo, es importante tener en cuenta que el efecto en el cliente será la ralentización de la acción tantos segundos como se marque en el tiempo de reintentos (por cada reintento).
Poniendo un caso práctico:
En la TPV, si el cobro de un Ticket tarda normalmente medio segundo, cuando de un error de interbloqueo en lugar de darse un error y que el usuario tenga que volver a pulsar el cobro (y exponerse a un nuevo error de interbloqueo), este error no se mostrará pero el cobro pasará de tardar medio segundo a tardar 1'5 segundos.
Obviamente si no hay error de interbloqueo seguirá tardando medio segundo en cobrarse, pero ese segundo adicional que ahorrará trabajo al usuario puede ser erróneamente percibido como lentitud del entorno. Y cuanto mayor sea el número de reintentos y el tiempo entre estos, mayor puede ser esta percepción.
NOTA:
Todo cambio en el fichero de configuración de la API requiere de un reinicio de la misma para que se apliquen los cambios.
¿Le ha sido útil este artículo?
¡Qué bien!
Gracias por sus comentarios
¡Sentimos mucho no haber sido de ayuda!
Gracias por sus comentarios
Sus comentarios se han enviado
Agradecemos su esfuerzo e intentaremos corregir el artículo