Em sistemas distribuídos, o controle de concorrência _____ permite que as transações prossigam sem qualquer forma de verificação até que sejam concluídas. As transações são validadas antes de poderem ser confirmadas. Assinale a alternativa que preenche corretamente a lacuna do trecho acima.
Apor separação
Bordenação por carimbo de tempo
Cpor bloqueios em duas fases
Dotimista
Epor aninhamento.
Revelar gabarito e comentário▾
GabaritoD — otimista
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”.
Controle de concorrência otimista em sistemas distribuídos
Gabarito: letra D. O controle de concorrência otimista é exatamente o que o enunciado descreve: as transações executam sem verificação prévia (otimisticamente) e só são validadas no momento da confirmação (commit). Esse é o conceito central da abordagem otimista, em contraste com as abordagens pessimistas, como bloqueios em duas fases e ordenação por carimbo de tempo, que verificam conflitos antes ou durante a execução.
O controle de concorrência é o mecanismo que garante que transações concorrentes (executadas ao mesmo tempo) não interfiram umas nas outras, preservando a consistência dos dados. Em sistemas distribuídos, isso é ainda mais desafiador porque os dados podem estar espalhados por vários nós. Existem duas grandes famílias de abordagens: as pessimistas e as otimistas.
Abordagens pessimistas (como bloqueios em duas fases e ordenação por carimbo de tempo) tentam evitar conflitos antes que eles aconteçam. No bloqueio em duas fases (2PL), a transação adquire bloqueios sobre os recursos que vai usar e só os libera no final, o que pode causar espera e até deadlocks. Na ordenação por carimbo de tempo, cada transação recebe um timestamp e as operações são ordenadas por esse timestamp, abortando transações que chegam "atrasadas". Ambas verificam conflitos durante a execução.
Abordagem otimista (também chamada de validação) parte do princípio de que conflitos são raros. A transação executa livremente, sem verificar nada, e só na fase de validação (antes do commit) é que se verifica se houve conflito com outras transações. Se houve, a transação é abortada e reiniciada; se não, é confirmada. É exatamente o que o enunciado descreve: "prossigam sem qualquer forma de verificação até que sejam concluídas" e "validadas antes de poderem ser confirmadas".
Vamos comparar as abordagens para fixar:
Critério
Otimista
Pessimista (2PL, timestamp)
Quando verifica conflito
Na validação (commit)
Durante a execução
Espera/bloqueio
Não bloqueia durante execução
Pode bloquear/esperar
Risco de abortar
Maior (se conflito)
Menor (evita conflito)
Adequado para
Ambientes com poucos conflitos
Ambientes com muitos conflitos
A pegadinha da banca é justamente inverter a lógica: as alternativas pessimistas (B e C) descrevem mecanismos que verificam durante a execução, não "sem qualquer forma de verificação". A alternativa D é a única que casa perfeitamente com a descrição do enunciado.
Alternativa A — ❌ Incorreta
"Controle por separação" não é um termo técnico consagrado em controle de concorrência. Não existe uma técnica chamada "separação" nesse contexto. A banca provavelmente criou esse distrator para confundir com a ideia de separar transações, mas não corresponde a nenhum mecanismo real de controle de concorrência.
Alternativa B — ❌ Incorreta
A ordenação por carimbo de tempo (timestamp) é uma abordagem pessimista: cada transação recebe um timestamp e as operações são ordenadas por ele, abortando transações que chegam atrasadas. Isso envolve verificação durante a execução, não "sem qualquer forma de verificação". O enunciado descreve exatamente o oposto: validação apenas no final.
Alternativa C — ❌ Incorreta
O bloqueio em duas fases (2PL) é a abordagem pessimista clássica: a transação adquire bloqueios sobre os recursos e os mantém até o final, verificando conflitos durante a execução. Isso causa espera e pode levar a deadlocks. Não se encaixa na descrição de "prossigam sem qualquer forma de verificação".
Alternativa D — ✅ Correta ⟵ GABARITO
O controle de concorrência otimista é exatamente o que o enunciado descreve: as transações executam livremente, sem verificação, e só na fase de validação (antes do commit) é que se verifica se houve conflito. Se houve, a transação é abortada; se não, é confirmada. É a abordagem que "permite que as transações prossigam sem qualquer forma de verificação até que sejam concluídas" e que "valida antes de confirmar".
Alternativa E — ❌ Incorreta
"Controle por aninhamento" não é um mecanismo de controle de concorrência. O termo "aninhamento" aparece em transações aninhadas (nested transactions), que é um modelo de transações dentro de transações, mas não é uma técnica de controle de concorrência. A banca usou esse termo para confundir, mas não corresponde ao conceito pedido.
NÃO CAIA NESSA!
A banca explora a confusão entre abordagens pessimistas e otimistas. As alternativas B e C descrevem mecanismos que verificam conflitos durante a execução (pessimistas), enquanto o enunciado pede exatamente o oposto: verificação apenas no final. O candidato que não domina a diferença entre "verificar antes" e "verificar depois" cai na armadilha. Lembre-se: otimista = executa primeiro, valida depois; pessimista = valida antes, executa depois.