LIBPQXX Transacción Serialización y Consecuencias

Question

Para mi implementación, se debe hacer una escritura particular a granel y sin la posibilidad de que otra interfiera.

He sido le dijo a que dos transacciones en competencia de esta manera conducirán a la primera que bloquean el segundo, y el segundo puede o no puede completarse después de la primera.

Publique la documentación que confirme esto. Además, ¿qué sucede exactamente con la segunda transacción si el primero está bloqueando? ¿Será colado, fallará o alguna combinación?

Si no se puede confirmar esto, ¿debe establecerse el nivel de aislamiento de transacción para esta transacción en SERIALIZABLEDODE? Si es así, ¿cómo se puede hacer con las declaraciones preparadas de LiBPQXX?

Si las transacciones están serializadas, ¿la segunda transacción fallará o se colocará hasta que se haya completado el primer?

Si falla, ¿cómo se puede detectar esto con LIBPQXX?

Answer 1

La única forma de prevenir de manera concentrativa los efectos de la concurrencia es LOCK TABLE ... IN ACCESS EXCLUSIVE MODE, cada tabla que desea modificar.

Esto significa que realmente solo estás haciendo una cosa a la vez. También conduce a problemas divertidos con puntos muertos si no siempre adquiere sus cerraduras en el mismo orden.

Por lo general, lo que necesita hacer es averiguar qué son exactamente las operaciones que desea hacer, y cómo interactúan. Determine qué efectos de concurrencia puede tolerar, y cómo prevenir a los que no puede.

Esta pregunta, ya que está muy ancha para responder de manera útil.

Las opciones incluyen:

• de bloqueo exclusivamente de las tablas. (Este es el Only Way para hacer un aumento de múltiples filas sin problemas de concurrencia en PostgreSQL en este momento). Tenga cuidado con la actualización de bloqueo y bloquee los puntos muertos relacionados con el pedido.

• Uso apropiado del aislamiento de SERIALIZABLE: pero recuerde, debe poder mantener un registro de lo que hizo durante una transacción y volver a intentarlo si el TX aborta.

• Cuidado de la fila de bloqueo - SELECT ... FOR UPDATE, SELECT ... FOR SHARE.

• "Bloqueo optimista" / control de concurrencia optimista, donde corresponda

• Escribir sus consultas de manera que los haga más amigables a la operación concurrente. Por ejemplo, reemplazando ciclos de escritura de modificación de lectura con actualizaciones en el lugar.