Directrices de codificación para evitar puntos muertos

Para salvar el problema de los puntos muertos, se recomienda ordenar la información a la que se va a acceder antes de provocar los bloqueos.

El término punto muerto hace referencia a una condición específica en una base de datos en que dos procesos están esperando a que otro proceso libere un recurso. Por ejemplo, cuando una aplicación cliente retiene un bloqueo en una tabla e intenta obtener el bloqueo en una segunda tabla retenida por otra aplicación cliente, esto puede provocar un punto muerto si la otra aplicación intenta obtener el bloqueo retenido por la primera aplicación.

Ordenar la información de una orden específica es aplicable a situaciones en que se necesite provocar varios bloqueos de artículos de inventario dentro de un único límite de transacción. Sin embargo, no es necesario ordenarla si llama a las API para procesar artículos individuales por confirmación de transacción.

Lectura de datos no confirmados en la base de datos DB2®

En Db2, cuando selecciona un registro de una tabla, se obtiene un bloqueo de lectura en el registro. Si el registro seleccionado se actualiza pero no se confirma, la hebra espera hasta que confirma los cambios. De forma alternativa, puede leer el registro con Lectura no confirmada (UR), en cuyo caso se proporciona al usuario el valor más reciente que se ha actualizado.

Puede leer datos no confirmados de cualquier API list estableciendo el atributo ReadUncommitted en Y en su XML de entrada. Para ello, debe personalizar el archivo JSP y pasar el atributo ReadUncommitted como un atributo oculto. Por ejemplo:

<input type="hidden" name="xml:/Order/@ReadUnCommitted" value="Y"/>

Como resultado, el escenario de bloqueo se elude en la base de datos Db2 . El bloqueo es el valor predeterminado en DB2.

No es obligatorio pasar este distintivo. Sin embargo, si lo establece en Y, el sistema se ve obligado a leer los datos no confirmados. Por ejemplo, una transacción, T1, actualiza la tabla TAB-1, pero la transacción de datos no está confirmada. Si el distintivo ReadUncommitted se establece en Y, otras transacciones pueden leer los datos no confirmados de la tabla TAB-1.

Antes de establecer este distintivo, evalúe las transacciones simultáneas para determinar si existe alguna situación en que se produzca un punto muerto. Si no se produce tal situación, el distintivo debe permanecer en su valor predeterminado.