LOCK

Descrição

O comando LOCK TABLE controla o acesso concorrente à tabela durante o tempo de execução da transação. O PostgreSQL sempre utiliza o modo de bloqueio menos restritivo quando é possível. O comando LOCK TABLE é usado nos casos onde se necessita de um modo de bloqueio mais restritivo.

Os bloqueios dos SGBDR utilizam a seguinte terminologia:

Por exemplo, suponha que um aplicativo processe uma transação no nível de isolamento READ COMMITTED e precise garantir a persistência dos dados da tabela durante a transação. Para conseguir esta persistência, pode-se obter o modo de bloqueio SHARE na tabela antes de realizar a consulta. Este procedimento impede alterações de dados concorrentes e garante que as operações de leitura posteriores na tabela acessam os dados no estado atual, porque o modo de bloqueio SHARE conflita com qualquer modo de bloqueio ROW EXCLUSIVE necessário para escrever. O comando LOCK TABLE nome IN SHARE MODE aguarda até que todas as operações de escrita concorrentes terminem efetivando ou desfazendo suas transações. Portanto, quando este bloqueio é conseguido, não existe nenhuma operação de escrita sendo executada.

Além dos requisitos acima, se uma transação altera os dados da tabela, então o modo de bloqueio SHARE ROW EXCLUSIVE deve ser obtido para prevenir a ocorrência da condição de "impasse" (deadlock), quando duas transações concorrentes bloqueiam a tabela em modo SHARE e depois tentam mudar os dados desta tabela, as duas (implicitamente) solicitando o modo de bloqueio ROW EXCLUSIVE que conflita com o modo de bloqueio SHARE concorrente.

Para que não ocorra a situação de "impasse" (quando duas transações ficam aguardando uma pela outra) descrita acima, devem ser seguidas duas regras gerais que evitam as condições de impasse:

• As transações têm que obter o bloqueio dos mesmos objetos na mesma ordem.

  Por exemplo, se um aplicativo atualiza a linha R1 e depois atualiza a linha R2 (na mesma transação), então um segundo aplicativo não deve atualizar a linha R2 se for atualizar a linha R1 depois (na mesma transação). Em vez disto, o segundo aplicativo deve atualizar as linha R1 e R2 na mesma ordem do primeiro aplicativo.

• As transações devem obter dois modos de bloqueio conflitantes somente se um deles é auto-conflitante (ou seja, pode ser obtido por somente uma única transação de cada vez). Se diversos modos de bloqueio estão envolvidos, então as transações devem sempre solicitar o modo mais restritivo primeiro.

  Um exemplo desta regra foi dado anteriormente ao se discutir o uso do modo SHARE ROW EXCLUSIVE em vez do modo SHARE.

Ao se bloquear várias tabelas, o comando LOCK a, b; é equivalente a LOCK a; LOCK b;. As tabelas são bloqueadas uma por uma na ordem especificada pelo comando LOCK.

Utilização

Este exemplo mostra o bloqueio no modo SHARE da tabela que contém a chave primária, antes de fazer uma inserção na tabela que contém a chave estrangeira:

BEGIN WORK;
LOCK TABLE filmes IN SHARE MODE;
SELECT id FROM filmes 
    WHERE nome = 'Star Wars: Episode I - The Phantom Menace';
-- Fazer o ROLLBACK se a linha não for encontrada
INSERT INTO filmes_comentarios VALUES 
    (_id_, 'Maravilhoso! Eu estava aguardando por isto há muito tempo!');
COMMIT WORK;
   

Obter o bloqueio no modo SHARE ROW EXCLUSIVE da tabela que contém a chave primária antes de realizar a operação de exclusão:

BEGIN WORK;
LOCK TABLE filmes IN SHARE ROW EXCLUSIVE MODE;
DELETE FROM filmes_comentarios WHERE id IN
    (SELECT id FROM filmes WHERE avaliacao < 5);
DELETE FROM filmes WHERE avaliacao < 5;
COMMIT WORK;
   

Compatibilidade