Prova 2 · Mapeamento O/R e Concorrência
Cap. 5, 11, 12, 13 e 16: Unit of Work, Identity Map, Lazy Load, mapeamento estrutural, herança, metadados e bloqueios offline
Objetivas
0/20 respondidas1.
Uma transação de negócio altera 3 objetos, cria 2 e remove 1. Ao final, o sistema precisa gravar tudo na ordem correta, em uma única transação de banco curta. Qual padrão coordena isso?
2.
Um relatório percorre 1.000 pedidos e acessa
pedido.getCliente(); cada acesso dispara uma consulta. Qual o nome do problema e a solução indicada?3.
Qual combinação é correta sobre os três padrões de herança?
4.
Uma hierarquia com 6 subclasses muda com frequência (campos sobem e descem na hierarquia), e consultas polimórficas são comuns. Qual esquema minimiza mudanças no banco?
5.
Emprego tem Periodo(inicio, fim) e Dinheiro(valor, moeda); Cliente tem uma árvore de departamentos nunca consultada por SQL. Quais mapeamentos?6.
Aluno e Turma têm relação muitos-para-muitos. Depois, o negócio passa a registrar nota e data de matrícula no vínculo. Como o mapeamento evolui?
7.
Por que o Identity Map deve ter escopo de sessão e não de processo?
8.
Ana e Bruno editam o mesmo contrato offline. Conflitos são raros e refazer é barato. Mais tarde, um processo de auditoria de 3 horas não pode perder trabalho. Que padrões usar em cada caso?
9.
UPDATE pedido SET ..., versao = 8 WHERE id = 3 AND versao = 7 retorna 0 linhas. Qual a interpretação e ação correta?10.
Uma equipe implementou Pessimistic Offline Lock, mas um desenvolvedor esqueceu de pedir o bloqueio em uma tela nova e houve sobrescrita. Qual padrão evitaria isso?
11.
Cliente e seus endereços devem ser editados juntos. Qual técnica evita gerenciar uma versão por endereço?
12.
Qual nível de isolamento evita leitura suja e leitura não repetível, mas ainda permite fantasmas?
13.
Por que transações de negócio longas não podem ser simplesmente transações de sistema longas?
14.
Um mapper concreto
GerenteMapper chama super.save() para gravar campos de Funcionario e depois grava os seus; FuncionarioMapper.find() decide qual concreto usar. Que padrão organiza isso e com quais esquemas funciona?15.
Qual alternativa justifica corretamente o uso de chave sem significado (surrogate) no Identity Field?
16.
Qual é a relação entre Metadata Mapping, Query Object e Repository?
17.
Um teste unitário de regras de cobrança precisa de clientes inadimplentes, sem banco. Qual padrão do cap. 13 torna isso simples?
18.
Faixa só existe dentro de Album. Uma nova feature permite que playlists referenciem faixas diretamente. O que muda?19.
Qual variação de Lazy Load é o objeto real parcialmente carregado, que se completa no primeiro acesso?
20.
Em controle otimista, uma regra de imposto usa o endereço do cliente, que foi apenas lido. Outro usuário muda esse endereço antes do commit. Qual problema e solução?
Dissertativas
autoavaliação · não entram na notaD1.
Explique como Unit of Work, Identity Map e Lazy Load trabalham juntos em uma arquitetura com Data Mapper.
Ver resposta modelo
Identity Map: ao carregar, o mapper consulta o mapa (id → objeto); garante um objeto por registro na sessão e evita recarregar.
Lazy Load: referências e coleções são carregadas só quando acessadas (lazy init, proxy, value holder, ghost), evitando grafos enormes; cuidado com N+1.
Unit of Work: rastreia novos, sujos e removidos; no commit abre transação curta, grava na ordem certa e aplica controle otimista.
Normalmente o Identity Map vive dentro do Unit of Work, por sessão/transação de negócio.
D2.
Compare Single Table, Class Table e Concrete Table Inheritance e indique um cenário para cada.
Ver resposta modelo
Single Table: uma tabela com discriminador. Prós: sem joins, consultas polimórficas fáceis, refatorar hierarquia sem mudar banco. Contras: colunas nulas, tabela confusa. Cenário: hierarquia rasa que muda muito.
Class Table: tabela por classe. Prós: esquema claro, sem nulos. Contras: joins, raiz como gargalo, refatorar muda tabelas. Cenário: banco consumido por outros sistemas, clareza importa.
Concrete Table: tabela por classe concreta com campos herdados. Prós: sem joins e sem nulos. Contras: duplicação, chaves únicas entre tabelas, consultas polimórficas com UNION. Cenário: subclasses consultadas isoladamente.
Inheritance Mappers organiza o código em qualquer caso.
D3.
Descreva Optimistic e Pessimistic Offline Lock, como cada um funciona e como escolher. Inclua Coarse-Grained Lock e Implicit Lock.
Ver resposta modelo
Otimista: versão em cada registro; UPDATE ... WHERE versao = lida; 0 linhas = conflito, rollback. Detecta tarde, escala bem; bom para conflitos raros e baratos.
Pessimista: gerenciador de bloqueios (tabela no banco ou memória); bloqueio exclusivo de escrita, de leitura ou leitura/escrita; timeout para sessões abandonadas. Evita conflito, reduz concorrência; bom para conflitos frequentes ou trabalho caro.
Coarse-Grained Lock: um bloqueio/versão para um grupo (versão compartilhada ou raiz do agregado).
Implicit Lock: infraestrutura (mapper, Layer Supertype) aplica o bloqueio automaticamente, para ninguém esquecer.
Os dois podem coexistir: otimista como padrão, pessimista em pontos críticos.