Como implementar corretamente o bloqueio otimista no MySQL

Como se implementa corretamente o bloqueio otimista no MySQL?

Nossa equipe deduziu que devemos fazer o item 4 abaixo ou existe o risco de que outro thread possa atualizar a mesma versão do registro, mas gostaríamos de validar que essa é a melhor maneira de fazê-lo.

1. Crie um campo de versão na tabela para o qual você deseja usar o bloqueio otimista, por exemplo, nome da coluna = "versão"
2. Ao selecionar, inclua a coluna da versão e anote a versão
3. Em uma atualização subsequente do registro, a instrução de atualização deve emitir "where version = X", em que X é a versão que recebemos no item 2 e defina o campo de versão durante essa instrução de atualização como X + 1
4. Execute um SELECT FOR UPDATEno registro que vamos atualizar para serializar quem pode fazer alterações no registro que estamos tentando atualizar.

Para esclarecer, estamos tentando impedir que dois encadeamentos que selecionam o mesmo registro na mesma janela de tempo em que eles capturam a mesma versão do registro substituam uns aos outros, caso tentem atualizar o registro ao mesmo tempo. Acreditamos que, a menos que façamos o número 4, há uma chance de que, se os dois threads inserirem suas respectivas transações ao mesmo tempo (mas ainda não emitiram suas atualizações), quando atualizarem, o segundo segmento que usará o UPDATE ... onde version = X estará operando em dados antigos.

Estamos corretos ao pensar que devemos fazer esse bloqueio pessimista ao atualizar, mesmo usando campos de versão / bloqueio otimista?

Seu desenvolvedor está enganado. Você precisa de um SELECT ... FOR UPDATE ou outro controle de versão, não de ambos.

Experimente e veja. Abertas três sessões MySQL (A), (B)e (C)para o mesmo banco de dados.

Em (C)questão:

CREATE TABLE test(
    id integer PRIMARY KEY,
    data varchar(255) not null,
    version integer not null
);
INSERT INTO test(id,data,version) VALUES (1,'fred',0);
BEGIN;
LOCK TABLES test WRITE;

Em ambos (A)e (B)emita um UPDATEque testa e define a versão da linha, alterando o winnertexto em cada um para que você possa ver qual sessão é qual:

-- In (A):

BEGIN;
UPDATE test SET data = 'winnerA',
            version = version + 1
WHERE id = 1 AND version = 0;

-- in (B):

BEGIN;
UPDATE test SET data = 'winnerB',
            version = version + 1
WHERE id = 1 AND version = 0;

Agora (C), UNLOCK TABLES;para liberar a trava.

(A)e (B)vai correr pelo bloqueio da linha. Um deles vai ganhar e conseguir o bloqueio. O outro irá bloquear na fechadura. O vencedor que conseguiu o bloqueio irá mudar de linha. Supondo que (A)seja o vencedor, agora você pode ver a linha alterada (ainda não confirmada e não visível para outras transações) com a SELECT * FROM test WHERE id = 1.

Agora, COMMITna sessão do vencedor, digamos (A).

(B)obterá o bloqueio e prosseguirá com a atualização. No entanto, a versão não corresponde mais e, portanto, não altera as linhas, conforme relatado pelo resultado da contagem de linhas. Apenas um UPDATEteve algum efeito, e o aplicativo cliente pode ver claramente qual UPDATEteve êxito e qual falhou. Nenhum bloqueio adicional é necessário.

Veja os logs da sessão em pastebin aqui . Eu usei mysql --prompt="A> "etc para facilitar a diferença entre as sessões. Copiei e colei a saída intercalada na sequência de tempo, portanto, não é uma saída totalmente bruta e é possível que eu tenha cometido erros ao copiar e colar. Teste você mesmo para ver.

Se você tivesse não adicionou um campo versão de linha, então você precisa SELECT ... FOR UPDATEpara ser capaz de garantir de forma confiável ordenação.

Se você pensar bem, a SELECT ... FOR UPDATEé completamente redundante se você estiver imediatamente fazendo uma UPDATEreutilização de dados do SELECT, ou se você estiver usando o controle de versão de linha. O UPDATEbloqueio será bloqueado de qualquer maneira. Se alguém atualizar a linha entre a leitura e a gravação subsequente, sua versão não corresponderá mais, portanto a atualização falhará. É assim que o bloqueio otimista funciona.

O objetivo de SELECT ... FOR UPDATEé:

• Gerenciar a ordem de bloqueio para evitar conflitos; e
• Para estender o período de um bloqueio de linha para quando você deseja ler dados de uma linha, altere-os no aplicativo e escreva uma nova linha baseada na original sem precisar usar SERIALIZABLEisolamento ou controle de versão de linha.

Você não precisa usar o bloqueio otimista (versão de linha) e SELECT ... FOR UPDATE. Use um ou outro.

UPDATE tbl SET owner = $me,
               id = LAST_INSERT_ID(id)
    WHERE owner = ''
    LIMIT 1;
$id = SELECT LAST_INSERT_ID();
Do some stuff (arbitrarily long time)...;
UPDATE  tbl SET owner = '' WHERE id = $id;

Sem bloqueios (sem tabela, sem transação) necessários ou mesmo desejados:

• UPDATE é atômico
• LAST_INSERT_ID () é específico da sessão, portanto, seguro para threads.