Eu li muitas fontes e elas dizem que uma das maneiras de implementar serializável no banco de dados é usar o bloqueio de duas fases. Mas eu realmente não entendo como o bloqueio de duas fases pode garantir a serialização neste exemplo de Jim Gray.
Um exemplo é que temos duas linhas no banco de dados, uma com o valor white e a outra com o valor black . Tenho duas transações:
- TX1 atualizará o valor de branco para preto
- TX2 atualizará o valor de preto para branco
Se TX1 e TX2 forem executados ao mesmo tempo, então TX1 adquire o bloqueio na linha com o valor de white , e TX2 adquire o bloqueio na linha com o valor de black . Portanto, não há conflitos de bloqueio e, eventualmente, os valores são trocados.
O bloqueio de duas fases (2PL) sozinho é insuficiente para garantir a serialização. Uma vez que permite que os bloqueios de gravação sejam liberados antes do final de nossa transação, o sistema também deve rastrear outras transações cujo conjunto de gravação se sobreponha ao conjunto de gravação de nossa transação. Os resultados dessas outras transações dependem de nossa transação ser confirmada ou revertida.
O bloqueio estrito de duas fases forte (SS2PL) mantém todos os bloqueios de leitura e gravação até o final de nossa transação. Outras transações não conseguem adquirir bloqueios em objetos nos quais já temos bloqueios. Portanto, não há necessidade de rastrear conjuntos de gravação sobrepostos, pois isso agora é impossível.
O nível de isolamento serializável não permite linhas fantasmas. Portanto, os tipos de bloqueio adotados por nossa transação também são importantes. Uma maneira é usar bloqueios de intervalo de chave em vez de bloqueios de chave única.
Aqui estão alguns slides de palestras que cobrem o tópico. 2PL começa em torno do slide 18, embora 1-17 sejam um bom plano de fundo. Eles incluem muitos cronogramas de transações que ilustram, passo a passo, as considerações.
Em alguns SGBDs o SS2PL não impede essa anomalia. As razões pelas quais consigo pensar incluem definições, implementação e predicados.
A definição acadêmica de serializável é que deve aparecer como se uma transação fosse concluída antes que a outra começasse. O padrão SQL, no entanto, o define como "sem linhas fantasmas". Estes não são equivalentes. A lacuna entre é onde essa anomalia se insinua.
Alto rendimento é uma coisa boa de se ter. Portanto, os projetistas de DBMS tendem a bloquear o mínimo possível. Nesse caso, seria a única linha "branca" (ou linha "preta" para a outra transação). Isso permite a anomalia. Se o bloqueio estivesse na mesa em vez de em uma linha, talvez por causa do escalonamento do bloqueio, não haveria anomalia. Fazer isso para cada consulta, no entanto, diminuiria o desempenho.
O UPDATE conforme escrito afirma que apenas as linhas brancas devem ficar pretas. Não tem nada a dizer sobre as linhas que começam em preto. Se fosse a intenção do programador que todas as linhas tivessem a mesma cor assim que a consulta fosse confirmada, isso poderia ser explícito omitindo o WHERE. Acredito que as implementações de bloqueio SS2PL existentes forneceriam o resultado serializável desejado. (Não estou dizendo que o programador está errado aqui, apenas mostrando outra lacuna.)
Suponho que seria possível para um sistema rastrear os predicados de gravação de cada transação e reverter qualquer um que se sobreponha a uma transação confirmada anteriormente. No momento em que você implementou isso, você está na maior parte do caminho para uma abordagem MVCC, então vá em frente.