Considerações de Programação do EJB Data Mediator Service
Ao começar a escrever seus aplicativos aproveitando a vantagem do serviço mediador de dados (DMS) do EJB (Enterprise JavaBeans) fornecido no produto, considere os itens a seguir.
Modelo de Programação EJB
Somente um subconjunto do modelo de
programação EJB é suportado pelo serviço mediador de dados do EJB.
- Ao usar os parâmetros de coleta EJB para recuperar os dados das instâncias EJB
ou ao usar applyChanges para atualizar as instâncias EJB:
- O EJB DMS utiliza interfaces locais para beans corporativos. As chamadas getter e setter para os campos CMP (Container-Managed Persistence) devem ser promovidas para a interface local, bem como quaisquer métodos EJB utilizados nas expressões de consulta.
- Para que o mediador crie um EJB, deve haver um método create que utilize
a classe de chave principal como o único método argument definido no EJB home. Se este método não existir, você deve fornecer um adaptador que manipule a operação
de criação. Além disso, a interface EJBLocalHome definida para o EJB deve incluir
(além do método create) o seguinte método:
findByPrimaryKey(<key class>) remove (java.lang.Object) create (<key class>)
- Ao chamar o método applyChanges diretamente para o banco de dados,
ocorre o seguinte:
- você ignora a atualização de contêiner. Você deve forçar uma atualização assim que possível por meio da terminação da transação e utilizando as opções apropriadas de cache do contêiner.
- você ignora a manutenção CMR (Container-Managed Relationship) EJB. Você deve contar com o RI de banco de dados para manter estes relacionamentos não recuperados no DataGraph.
- Os campos CMP devem ser os tipos permitidos. Consulte Sintaxe de Consulta do Mediador EJB para obter uma lista desses tipos.
- Os campos CMP de tipos definidos pelo usuário que utilizam conversores/compositores EJB não são suportados.
A tabela a seguir mostra limitações no modelo de programação EJB que não são suportadas pelo EJB DMS.
recuperar direto do bd | recuperar do Contêiner EJB | atualizar direto para o bd | atualizar por meio de EJB | |
---|---|---|---|---|
Herança de persistência EJB | NÃO | NÃO | NÃO | NÃO |
Campo EJB cmp com conversor | NÃO | Yes | NÃO | Yes |
Transacional
- Todas as chamadas do mediador, incluindo create, devem ser feitas em um escopo de transação – seja uma transação do usuário ou uma transação do contêiner. As diversas chamadas do mediador, incluindo create, getGraph e applyChanges, não precisam ser chamadas na mesma transação. De fato, mais frequentemente as chamadas são feitas em transações separadas.
Intenção de Acesso
- Quando a consulta do mediador faz referência a um EJB utilizando seu ASN (Abstract Schema Name), os dados são recuperados diretamente do banco de dados. A intenção de acesso e o nível de isolamento utilizados na conexão de origem de dados é a intenção de acesso especificada no perfil do aplicativo para intenção de acesso da consulta dinâmica EJB. É recomendado que você defina uma intenção de acesso otimista para seu aplicativo porque um DataGraph deve ser utilizado em um modelo de programação desconectado.
- Quando o mediador está recuperando dados utilizando uma coleta EJB, a intenção de acesso especificada no perfil do aplicativo será utilizada se o EJB precisar de ativação.
- Durante applyChanges, o controle de simultaneidade otimista é utilizado para verificar determinados campos no DataObject antes de aplicar alterações no banco de dados. As atualizações são normalmente processadas sob uma transação diferente da recuperação. No entanto, para evitar atualizações perdidas é necessário verificar se outra transação não atualizou os dados. Ao definir o mapeamento EJB para RDB, você pode especificar um ou mais campos EJB como Predicados otimistas. Os campos são utilizados para verificação ao comparar o valor atual do banco de dados com o valor antigo do
registro de mudanças do DataGraph. Se a verificação for bem-sucedida, então, o valor atual dos campos serão gravados no banco de dados. Se a
comparação retornar false e a atualização falhar, ocorrerá uma exceção. Tudo isso é executado em uma única instrução de atualização com predicados extras incluídos, como no seguinte exemplo. O campo optimisticPredicate é myColumn1.
update myTable set myColumn1="new value1", myColumn2="new value2"where myKey="key value" and myColumn1="old value1"
- Quando applyChanges for feito por meio do contêiner EJB, os valores atuais dos beans corporativos serão comparados aos antigos valores dos campos de predicados otimistas. Se os valores forem desiguais, ocorrerá uma exceção.
- Contanto que você tenha definido um ou mais campos EJB como optimisticPredicates, então, para que o SDO seja atualizável, pelo menos um dos campos optmisticPredicate deverá ser ser recuperado no objeto de dados. Caso contrário, applyChanges retornará uma exceção. O campo deve ser atualizado pelo responsável pela chamada ou por um acionador do banco de dados – o mediador não incrementa ou define automaticamente o campo.
- Nem todos os campos são verificados, apenas aqueles campos marcados como optimisticPredicate no mapeamento EJB-RDB.
- Observe que a ferramenta de mapeamento do EJB fornece a possibilidade de nenhum campo optimisticPredicate. Nesse caso, o mediador executará atualizações sem qualquer verificação.
- A criação e a exclusão de operações não fazem uso dos campos de predicado otimistas.
- Ao aplicar mudanças por meio de instâncias EJB, o EJB poderá ter sido ativado primeiro. Nesse caso, aplica-se a intenção de acesso adequada associada aos métodos EJB. É recomendável executar applyChanges em um perfil que tenha intenção de acesso pessimista, caso contrário, a lógica de simultaneidade otimista será chamada duas vezes – uma ao copiar valores de objetos de dados para o EJB e uma segunda vez, quando o gerenciador de persistência comparar os valores antigos dos valores do campo EJB com o registro do banco de dados.
- A intenção de acesso utilizada pelo mediador ao recuperar diretamente do banco de dados é a intenção de acesso padrão definida para o EJB nomeado na primeira instrução de consulta.
Práticas Recomendáveis
- É possível chamar getGraph em uma instância mediadora, atualizar o DataGraph retornado e, em seguida, chamar applyChanges em uma instância mediadora diferente. No entanto, embora eles não precisem da mesma instância de mediador, eles precisam do mesmo formato de consulta. O formato de consulta é o número e o pedido de instruções de consulta, os campos e relacionamentos especificados nas cláusulas SELECT e FROM e assim por diante.
- Evite chamadas repetidas para createMediator, se possível. Utilize as consultas de parâmetro e utilize getGraph para transmitir diferentes valores de parâmetro.