Julgue o próximo item, relativos a tecnologias backend.Em relação à gestão de bloqueio em um banco de dados relacional, o Hibernate 6.2 utiliza a estratégia otimista, uma vez que essa estratégia assume que várias transações podem ser concluídas sem afetar outras, logo, nessa versão, prescinde-se da estratégia pessimista.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
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”.
Hibernate – Estratégias de bloqueio (locking)
❌ ERRADO. O Hibernate 6.2 não prescinde da estratégia pessimista; ele oferece ambas as estratégias (otimista e pessimista) e o desenvolvedor pode escolher qual utilizar conforme os requisitos da aplicação.
A afirmação sugere que, por utilizar a estratégia otimista, o Hibernate 6.2 abandona a pessimista, o que é incorreto. O Hibernate sempre suportou os dois modos de locking:
Otimista (Optimistic Locking): Assume conflitos raros e verifica a integridade no momento da escrita (geralmente via versão ou timestamp).
Pessimista (Pessimistic Locking): Bloqueia os registros durante a transação para evitar concorrência, usando SELECT FOR UPDATE ou locks explícitos.
Ambas estão disponíveis no Hibernate 6.2, assim como nas versões anteriores. A escolha depende do cenário: aplicações com alta concorrência de escrita podem se beneficiar do locking pessimista, enquanto cenários com baixa contenção favorecem o otimista. Nenhuma versão do Hibernate "prescinde" de uma das estratégias – elas coexistem.
SE LIGUE NESSA!
Cuidado com afirmações absolutas como "prescinde-se da estratégia pessimista". Frameworks maduros como Hibernate mantêm funcionalidades legadas e alternativas, mesmo que uma abordagem seja mais recomendada para determinados casos.