Pular para o conteúdo principal

Questão de Banco de Dados — Gerência de Transações — CESPE / CEBRASPE 2025

Banco de DadosGerência de Transações
Código
ce195369
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 um ambiente de banco de dados de um sistema bancário, duas transações são executadas simultaneamente: uma delas adquire bloqueio exclusivo em A e, em seguida, em B; a outra adquire bloqueio exclusivo em B e, em seguida, em A. Ambas só liberam todos os bloqueios ao término da execução.Nesse cenário, é mais provável que ocorra
  1. Astarvation da transação mais lenta, sendo a melhor prevenção a implementação de um escalonador baseado em prioridades.
  2. Bviolação de isolamento, sendo a melhor prevenção a elevação do nível de isolamento para serializable.
  3. Cdetecção de deadlock por timeout, sendo a melhor prevenção a imposição de limites de tempo para a aquisição de bloqueios.
  4. Ddeadlock, sendo a melhor prevenção a imposição de uma ordenação total aos recursos, exigindo-se que todas as transações adquiram bloqueios em uma mesma sequência predefinida.
  5. Econdição de corrida (race condition), sendo a melhor prevenção a utilização de bloqueios compartilhados em vez de exclusivos.
Revelar gabarito e comentário

GabaritoD — deadlock, sendo a melhor prevenção a imposição de uma ordenação total aos recursos, exigindo-se que todas as transações adquiram bloqueios em uma mesma sequência predefinida.

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”.

Transações Concorrentes e Deadlock

Gabarito: letra D. O cenário descrito — duas transações adquirem bloqueios exclusivos em recursos em ordem inversa (A→B e B→A) e só liberam ao final — gera uma espera circular clássica, configurando deadlock. A prevenção mais eficaz é impor uma ordenação total dos recursos, de modo que todas as transações solicitem bloqueios sempre na mesma sequência (por exemplo, sempre A antes de B).

A banca testa o conhecimento sobre problemas de concorrência em banco de dados, especialmente o deadlock e suas condições de ocorrência. A situação de locks em ordem invertida é um exemplo típico de deadlock.

1Causa
Locks exclusivos em ordem inversa
Espera circular
2Condições (Coffman)
Exclusão mútua
Posse e espera
Não preempção
Espera circular
3Prevenção
Ordenação total dos recursos
Lock ordering (A → B sempre)
4Tratamento
Timeout
Detecção de ciclo
Deadlock
LEVELsoulevel.com.br
Deadlock: Causa (Locks exclusivos em ordem inversa, Espera circular); Condições (Coffman) (Exclusão mútua, Posse e espera, Não preempção, Espera circular); Prevenção (Ordenação total dos recursos, Lock ordering (A → B sempre)); Tratamento (Timeout, Detecção de ciclo)

Alternativa A — ❌ Incorreta

A starvation (adiamento infinito de uma transação) ocorre quando uma transação nunca consegue obter o recurso, geralmente por prioridades baixas. O cenário não descreve prioridade, mas sim um impasse entre duas transações que já detêm recursos um do outro. A prevenção por prioridade não resolve o deadlock.

Alternativa B — ❌ Incorreta

A violação de isolamento ocorre quando uma transação lê dados não confirmados de outra, causando dirty read, non-repeatable read ou phantom read. O problema aqui não é de isolamento, mas de conflito de locks que leva a impasse. Elevar o isolamento para serializable pode até aumentar a chance de deadlock, não o previne.

Alternativa C — ❌ Incorreta

A detecção de deadlock por timeout é uma técnica de tratamento, não de prevenção. Além disso, o cenário é de deadlock, não de timeout simples. A melhor prevenção, como dito, é a ordenação de recursos, não limites de tempo — que apenas detectam após ocorrido.

Alternativa D — ✅ Correta ⟵ GABARITO

Exatamente: duas transações, cada uma segurando um lock que a outra precisa, formam uma espera circular — deadlock. A imposição de uma ordenação total dos recursos (por exemplo, adquirir locks sempre em ordem crescente de identificador) quebra a circularidade, prevenindo o deadlock (conhecida como técnica de lock ordering ou prevenção de deadlock).

Alternativa E — ❌ Incorreta

Condição de corrida (race condition) ocorre quando o resultado depende da ordem de execução das transações, geralmente sem locks adequados. No cenário, os locks exclusivos já estão sendo usados, mas em ordem reversa, gerando deadlock. Usar locks compartilhados em vez de exclusivos não previne o deadlock, pois o problema não é de leitura/escrita simultânea, e sim de locks conflitantes.

Conclusão: A situação caracteriza deadlock, e a prevenção mais adequada é a ordenação global dos recursos. Gabarito: letra D.

Link permanente: /questoes/ce195369