Bloqueo de transacción

Las transacciones tienden a serializar el sistema y dejarlo más lento en entornos multiusuario. Para mitigar la serialización son necesarios algunos cuidados.
El primer cuidado a tomarse, es evitar un DeadLock. Un sistema está en estado de DeadLock cuando existe una operación (A) haciendo un bloqueo en un registro (L1) e intentando bloquear otro registro (L2). En este mismo momento existe otra operación (B) bloqueando el registro (L2) e intentando bloquear el registro (L1). En esta situación no hay forma de que el banco resuelva las solicitudes, entonces elige aleatoriamente, una de las conexiones y la finaliza provocando un error para el usuario.

Existen dos maneras de resolver un DeadLock. La primera es garantizar que la transacción no bloquee más de un registro de la misma tabla. Esto puede realizarse reduciendo el tamaño de la transacción, para garantizar y mantener la integridad del sistema.
Ejemplo: Cuando se graba un formulario del tipo Master/Detail puede realizarse una transacción para el Master y el primer registro Detail y otra para los otros ítems.
// DeadlockPreventionSample.prw
For nX := 1 to Len(aCampos)
Begin Transaction
If nX == 1
RecLock("SC5", .T.)
EndIf
RecLock("SC6",.T.)
MaAvalSc6()
End Transaction Lockin "SC5"
Next nX
Begin Transaction
RecLock("SC5")
MaAvalSc5()
End Transaction
Observe que durante todo el proceso, la tabla SC5 está bloqueada y solamente se liberará en la última transacción. Esto lo garantiza el comando CLOSETRANSACTION LOCKIN, que actualiza la transacción, pero mantiene el bloqueo del registro para no generar problemas en otros procesamientos concurrentes, de acuerdo con lo informado anteriormente.
Otra manera de resolver, es utilizando la función MultLock. Esta función garantiza el bloqueo de todos los registros de una misma tabla. Su desventaja es el aumento de la serialización del producto. Por este motivo, debe utilizarse con mucho cuidado y tener presente que siempre hay una alternativa para evitar su uso.
// MultlockSample.prw
If MultLock("SB2",aMults,1)
Begin Transaction
// Hace alguna cosa
End Transaction
EndIf
La selección de uno de los métodos dependerá del tipo de transacción.
Las transacciones de formulario, obligatoriamente deben seguir el primer ejemplo. Las transacciones son más rápidas y el riesgo es la actualización parcial del formulario digitado, sin embargo, este quedara íntegro. Con toda seguridad el usuario final prefiere perder algunos datos a todo.
Sin embargo, existirán casos en que la actualización parcial no proporciona una transacción íntegra. Para estos casos, debe utilizarse "MultLock". Un buen ejemplo son las facturas, que en caso de interrupción, el usuario tiende a anular la factura y rehacerla si faltan ítems, es decir, el modelo anterior no proporciona beneficios al usuario.