El bloqueo optimista es una estrategia en la que lee un registro, toma nota de un número de versión (otros métodos para hacer esto incluyen fechas, marcas de tiempo o sumas de verificación/hashes) y verifica que la versión no haya cambiado antes de volver a escribir el registro. Cuando vuelve a escribir el registro, filtra la actualización en la versión para asegurarse de que sea atómica. (es decir, no se ha actualizado entre el momento en que verifica la versión y escribe el registro en el disco) y actualiza la versión de una sola vez.
Si el registro está sucio (es decir, una versión diferente a la suya), cancela la transacción y el usuario puede reiniciarla.
Esta estrategia es más aplicable a sistemas de alto volumen y arquitecturas de tres niveles donde no necesariamente mantiene una conexión a la base de datos para su sesión. En esta situación, el cliente no puede mantener los bloqueos de la base de datos, ya que las conexiones se toman de un grupo y es posible que no esté utilizando la misma conexión de un acceso al siguiente.
El bloqueo pesimista es cuando bloquea el registro para su uso exclusivo hasta que haya terminado con él. Tiene una integridad mucho mejor que el bloqueo optimista, pero requiere que tenga cuidado con el diseño de su aplicación para evitar interbloqueos. Para usar el bloqueo pesimista, necesita una conexión directa a la base de datos (como suele ser el caso en una aplicación de servidor de cliente de dos niveles) o una identificación de transacción disponible externamente que se puede usar independientemente de la conexión.
En el último caso, abre la transacción con el TxID y luego se vuelve a conectar con ese ID. El DBMS mantiene los bloqueos y le permite recuperar la sesión a través del TxID. Así es como funcionan las transacciones distribuidas que utilizan protocolos de confirmación de dos fases (como transacciones XA o COM+).
