LOCK [ TABLE ] name LOCK [ TABLE ] name IN [ ROW | ACCESS ] { SHARE | EXCLUSIVE } MODE LOCK [ TABLE ] name IN SHARE ROW EXCLUSIVE MODE |
El nombre de una tabla existente para bloquear.
A este modo de bloqueo se accede autom�ticamente sobre tablas que estan siendo consultadas. Postgres libera autom�ticamente los bloqueos accedidos ACCESS SHARE despues de que se haya hecho la sentencia. |
Este es el modo de bloqueo menos restrictivo el cual entra en conflicto s�lo con el modo ACCESS EXCLUSIVE . Se pretende proteger una tabla que est� siendo consultada de sentencias concurrentes ALTER TABLE, DROP TABLE y VACUUM sobre la misma tabla.
Se accede autom�ticamente por cualquier declaraci�n SELECT FOR UPDATE. |
Conflictos con los modos de bloqueo EXCLUSIVE y ACCESS EXCLUSIVE.
Se accede autom�ticamente por cualquier sentencia UPDATE, DELETE, INSERT. |
Conflictos con los modos SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE ACCESS EXCLUSIVE. Generalmente significa que una transacci�n actualiza o inserta algunas tuplas en una tabla.
Se accede autom�ticamente por cualquier sentencia CREATE INDEX |
Conflictos con los modos ROW EXCLUSIVE, SHARE ROW EXCLUSIVE, EXCLUSIVE y ACCESS EXCLUSIVE . Este modo protege una tabla contra actualizaciones concurrentes.
Conflictos con los modos ROW EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE y ACCESS EXCLUSIVE. Este modo es m�s restrictivo que el modo SHARE debido a que s�lo puede soportar este bloqueo una transacci�n por vez .
Conflictos con los modos ROW SHARE, ROW EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE y ACCESS EXCLUSIVE modes. Este modo es a�n m�s restrictivo que �se de SHARE ROW EXCLUSIVE; bloquea todas las consultas concurrentes SELECT FOR UPDATE .
Se accede autom�ticamente por las sentencias ALTER TABLE, DROP TABLE, VACUUM . |
Este es el modo de bloqueo m�s restrictivo y es incompatible con todos los dem�s modos de bloqueo y protege una tabla bloqueada de cualquier otra operaci�n concurrente.
Este modo de bloqueo se accede tambi�n por un LOCK TABLE sin cualificar. (i.e. el comando sin una opci�n de bloqueo expl�cita). |
Postgres siempre usa el modo de bloqueo menos restrictivo cuando le es posible. LOCK TABLE toma medidas para cuando se pueda necesitar un modo de bloqueo mas restrictivo.
Por ejemplo, una aplicaci�n ejecuta una transacci�n en el nivel de aislamiento READ COMMITTED y necesita asegurar la existencia de datos en una tabla para la duracion de la transacci�n. Para ello t� podr�as usar el modo de bloqueo SHARE sobre la tabla antes de la consulta. Esto proteger� los datos de cambios concurrentes y proporcionar� cualquier otra operaci�n de escritura sobre la tabla con datos en su verdadero estado actual, porque el modo de bloqueo SHARE es incompatible con cualquier ROW EXCLUSIVE accedido por los que esriben, y LOCK TABLE "tabla" en sentencia IN SHARE MODE esperar� hasta que se produzca o se "baje" cualquier operaci�n de escritura concurrente.
Para leer datos en su verdadero estado actual cuando ejecutas una transacci�n en el nivel de aislamiento SERIALIZABLE tienes que ejecutar una declaraci�n LOCK TABLE antes de la ejecuci�n de cualquier sentencia DML, cuando la transacci�n define qu� cambios concurrentes ser�n visibles por ellos mismos. |
Adem�s de los requerimientos precedentes, si una transacci�n va a cambiar datos en una tabla entonces se deber�a acceder al modo SHARE ROW EXCLUSIVE para evitar condiciones de punto muerto cuando dos transacciones coincidentes intentan bloquear la tabla en modo SHARE y entonces intentan cambiar datos en esta tabla, ambas (implicitamente) accediendo al modo de bloqueo ROW EXCLUSIVE que es incompatible con el bloqueo SHARE .
Para continuar con los puntos muertos (cuando dos transacciones se esperan la una a la otra) tema tratado arriba, deber�as seguir dos reglas generales para evitar condiciones de punto muerto :
Las transacciones tienen que acceder a bloqueos de los mismos objetos en el mismo orden.
Por ejemplo, si una aplicaci�n actualiza la fila R1 y despu�s actualiza la fila R2 (en la misma transacci�n) entonces la segunda aplicaci�n no deber�a actualizar la fila R2 si ello va a actualizar la fila R1 m�s tarde (en una transacci�n simple). En cambio, deber�a actualizar la fila R1 y R2 en el mismo orden como en la primera aplicaci�n.
Las transacciones deber�an procurarse dos modos de bloqueo conflictivos s�lo si uno de ellos es auto-conflictivo (i.e. podr�a ser soportado por s�lo una transacci�n cada vez). Si estan involucrados modos de bloqueo m�ltiples, entonces las transacciones deber�an siempre acceder primero al modo m�s restrictivo.
Un ejemplo para esta regla se di� antes cuando se discuti� el uso del modo SHARE ROW EXCLUSIVE mejor que el modo SHARE.
Postgres no detecta puntos muertos "bajar�" una transacci�n a la espera para resolver el punto muerto. |
Illustrate a SHARE lock on a primary key table when going to perform inserts into a foreign key table:
BEGIN WORK; LOCK TABLE pel�culas IN SHARE MODE; SELECT id FROM pel�culas WHERE name = 'Star Wars: Episodio I - La amenaza fantasma'; -- Haz ROLLBACK si el registro no fue devuelto INSERT INTO comentarios_usuario_pel�culas VALUES (_id_, 'GUAY! Llevaba tanto tiempo esper�ndola!'); COMMIT WORK; |
Toma un bloqueo SHARE ROW EXCLUSIVE clave de tabla primaria cuando vayas a hacer una operaci�n de borrado:
BEGIN WORK; LOCK TABLE pel�culas IN SHARE ROW EXCLUSIVE MODE; DELETE FROM comentarios_usuario_pel�culas WHERE id IN (SELECT id FROM pel�culas WHERE clasificaci�n < 5); DELETE FROM pel�culas WHERE clasificaci�n < 5; COMMIT WORK; |
No hay LOCK TABLE en SQL92, que usa en cambio SET TRANSACTION para especificar niveles de concurrencia en transacciones. Nosotros tambi�n la tenemos; ver SET para m�s detalles.