Protocolo de bloqueio de duas fases
-antes de operar sobre qualquer objeto, uma transação deve adquirir um bloqueio
sobre esse objeto (compartilhado ou exclusivo)
-depois de liberar um bloqueio, uma transação nunca deve adquirir outros bloqueios
C.J.Date
C.J. Date quando fala em leitura fantasma mostra um exemplo de aplicação "errada" do protocolo.
Uma aplicação de somar saldos de contas.
Ele bloqueia cada conta ao adicionar seu saldo a soma total. (e só vai liberá-las no final)
O problema é que desse jeito uma outra transação pode adicionar uma conta nova, antes mesmo do termina da
transação em questão.
Ou seja a aplicação bloqueia tuplas, enquanto deveria ter bloqueado a tabela { mais precisamente a RelVar}
Seguindo ao pé da letra a aplicação utilizou o objeto tabela de contas, sem bloqueá-la, logo não está de acordo com o protocolo.
Por outro lado a gente sabe que nem sempre que se utiliza os valores de uma tupla é necessário bloquear a tabela.
Ou seja a banca pode acabar puxando para qualquer um dos lados. Dizer que escolher a granularidade errada é aplicar o protocolo de forma errada (logo a questão estaria certa) ou dizer que algumas aplicações mesmo seguindo o protocolo podem ter problemas de serializabilidade caso escolham a granularidade errada (logo a resposta seria falso).
Difícil é saber para onde a banca vai puxar.
Em todo caso, a resposta escolhida pela banca me parece a correta (leva o protocolo ao pé da letra), complicado seria ganhar no recurso caso ela tivesse escolhido a outra resposta.
"Pode ser provado que, se cada transação em um schedule seguir o protocolo de bloqueio em duas fases, o schedule é garantidamente serializável, evitando a necessidade de testar a serialização dos schedules. O protocolo de bloqueio, ao impor as regras de bloqueio em duas fases, também impõe a serialização "
Sistemas de Bancos de Dados, Navathe, 6ª Edição, página 527.