Recuperarse de errores de transacciones debido al bloqueo optimista

Existen tres estrategias principales que puede utilizar para recuperarse de transacciones fallidas si hay colisiones en la base de datos debido a un bloqueo optimista: Serialización, reintentar, ignorar. Estas estrategias están supeditadas a la importancia o a lo perentorio de la transacción en cuestión.

Procedimiento

Serialización
La primera estrategia es serializar la transacción que está fallando. La serialización fuerza el orden de las operaciones en la base de datos para garantizar que ninguna otra transacción actualiza el mismo conjunto de resultados entre la hora en que una transacción lee y graba un conjunto de resultados. En otras palabras, la serialización sobre un determinado conjunto de operaciones de base de datos permite la anulación temporal de la libertad que ofrece el bloqueo de tipo optimista.
Por ejemplo, si muchos usuarios distintos realizan frecuentemente una transacción determinada, la probabilidad de que se produzcan colisiones durante el mismo conjunto de operaciones es alta. La serialización contribuye a encauzar a los usuarios a través de dicha sección de operaciones, una por una, pasando temporalmente a una estrategia más pesimista mientras se opera con la sección de código crítica.
La serialización resulta ventajosa cuando:
- La transacción es de naturaleza crítica y no se desea fallar en transacciones críticas.
- Es probable que la actualización en la base de datos cause una alta frecuencia de colisiones.
Nota: De forma predeterminada, la tabla INVENTORY se serializa utilizando Select for Update.
La serialización puede aumentar el rendimiento para dicha operación cuando el error efectuado es alto sin ella (es decir se producen frecuentemente colisiones) evitando reintentar la operación.
La aparición de una de las excepciones siguientes en el registro de HCL Commerce indica que se puede haber producido una anomalía de actualización optimista:

com.ibm.ejs.persistence.OptimisticUpdateFailureException: executeUpdate ha devuelto cero filas actualizadas

La excepción cuando la anomalía se produce es cuando el contenedor EJB intenta actualizar el bean de entidad.

com.ibm.commerce.base.helpers.ECJDBCOptimisticUpdateFailureException

La excepción cuando se produce la anomalía es cuando un bean de sesión intenta actualizar una fila en una tabla de base de datos utilizando una conexión de base de datos JDBC.

Para forzar (o serializar) a que las sentencias SELECT y UPDATE se produzcan una después de la otra, cambie el nivel de aislamiento de la operación actual por ReadStability.
- Cambie la sentencia SELECT problemática por SELECT . . . FOR UPDATE WITH RS.
- Cambie la sentencia SELECT por SELECT . . .FOR UPDATE.
Nota: Para la serialización de beans EJB, no modifique beans existentes. En su lugar, introduzca las consultas JDBC que utilizan SELECT ... FOR UPDATE, tal como se ha mostrado en el ejemplo anterior.
Reintento
La segunda estrategia consiste en repetir el mandato que no se ejecuta correctamente. Existe un mecanismo en el que el motor de Transaction server que le permite volver a ejecutar un mandato si se produce un error.
Consulte el archivo Hacer que los mandatos de controlador puedan reintentarse.
El valor predeterminado de la propiedad retriable es true. Una implementación de mandato puede alterar temporalmente este valor, aunque la forma normal de hacerlo sin cambiar el código es especificándolo de forma explícita en el valor de columna PROPERTIES de la tabla de base de datos CMDREG. Por ejemplo, si el valor de la columna CMDREG.PROPERTIES especifica retriable=false, el mandato no se reintentará cuando se retrotraiga su transacción de base de datos.
El hecho de reintentar la ejecución de un mandato que no se ha ejecutado correctamente resulta beneficioso cuando las posibilidades de colisión son bajas. Reintentar la ejecución de un mandato es más caro que la serialización pero, para las operaciones que no colisionan frecuentemente, es preferible.
Ignorar
Si las transacciones que están fallando no son significativas (los usuarios finales pueden renovar sus navegadores y continuar) puede ignorar el error.