Questão de Banco de Dados — Gerência de Transações — CESPE / CEBRASPE 2025
Banco de Dados›Gerência de Transações
Código
ce195372
Banca
CESPE / CEBRASPE
Órgão
BANRISUL
Ano
2025
Nível
Superior
Cargo
Técnico em Tecnologia da Informação II - Área: Administração de Banco de Dados
Em sistemas de gerenciamento de banco de dados, o controle de concorrência tem como objetivo garantir que múltiplas transações executadas simultaneamente não comprometam a integridade dos dados. Um dos principais protocolos utilizados nesses sistemas é o 2PL (two-phase locking). Acerca desse protocolo, assinale a opção correta.
AO protocolo 2PL estrito exige que todos os bloqueios sejam liberados após a fase de crescimento, antes do commit.
BO protocolo 2PL estrito garante serializabilidade ao manter os bloqueios até o final da transação.
CO 2PL básico impede completamente a ocorrência de interbloqueios (deadlocks).
DO protocolo 2PL não se aplica a bancos de dados que utilizam transações distribuídas.
EO uso de bloqueios pessimistas elimina a necessidade de controle de concorrência.
Revelar gabarito e comentário▾
GabaritoB — O protocolo 2PL estrito garante serializabilidade ao manter os bloqueios até o final da transação.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Protocolo 2PL (Two-Phase Locking) e Controle de Concorrência
Gabarito: letra B. O protocolo 2PL estrito garante serializabilidade ao manter todos os bloqueios até o final da transação (commit ou abort), diferentemente do 2PL básico, que permite liberar bloqueios antes do commit (shrink phase). Essa é a característica que diferencia a versão estrita e a torna mais segura contra aborts em cascata.
Protocolo 2PL: 2PL básico (Fase de crescimento (adquire locks), Fase de encolhimento (libera locks), Permite aborts em cascata, Não impede deadlocks); 2PL estrito (strict) (Mantém locks até o commit/abort, Garante serializabilidade, Schedules recuperáveis, Evita aborts em cascata); Aplicações (Bancos centralizados, Bancos distribuídos (distributed 2PL))
Alternativa A — ❌ Incorreta
Afirma que no 2PL estrito os bloqueios são liberados após a fase de crescimento, antes do commit. Na verdade, no 2PL estrito (strict 2PL), todos os bloqueios (tanto de leitura quanto de escrita) são mantidos até o commit ou abort. A fase de encolhimento (shrink) só ocorre após o término da transação. Liberar bloqueios antes do commit é característica do 2PL básico, não do estrito.
Alternativa B — ✅ Correta ⟵ GABARITO
O 2PL estrito mantém os bloqueios até o final da transação, garantindo que nenhum lock seja liberado antes do commit. Isso assegura a serializabilidade do schedule, pois impede que transações concorrentes vejam dados inconsistentes. Além disso, schedules produzidos por strict 2PL são recuperáveis e evitam aborts em cascata.
Alternativa C — ❌ Incorreta
O 2PL básico não impede deadlocks. Deadlocks podem ocorrer quando duas ou mais transações esperam por locks que estão retidos entre si. O gerenciamento de deadlocks (detecção, prevenção ou espera) é necessário também em protocolos baseados em bloqueio. A afirmação é falsa.
Alternativa D — ❌ Incorreta
O protocolo 2PL é perfeitamente aplicável a bancos de dados distribuídos. Existem variantes como o distributed 2PL, que sincroniza locks entre sites para garantir serializabilidade global. A afirmação é falsa.
Alternativa E — ❌ Incorreta
Bloqueios pessimistas (como os usados no 2PL) são uma forma de controle de concorrência, e não o eliminam. O controle de concorrência é justamente necessário para garantir isolamento; bloqueios são a ferramenta para implementá-lo. A frase "elimina a necessidade" é equivocada.
NÃO CAIA NESSA!
A alternativa A inverte a regra do 2PL estrito — a banca troca "antes do commit" por "após o commit". Lembre-se: strict 2PL prende os locks até o fim; só os libera depois do commit. A alternativa C também é clássica: confundir 2PL com deadlock-free (falso). Grave: 2PL não evita deadlocks.