ADF: JBO-25014: Another user has changed the row with primary key

Ao trabalhar com o framework Oracle ADF 11g é muito comum nos depararmos com o famigerado erro JBO-25014: Another user has changed the row with primary key, no qual significa que 2 usuários tentaram modificar o mesmo registro no banco ao mesmo tempo. Na verdade, o que acontece é que o framework está alertando o último usuário que o registro que ele previamente havia carregado em tela foi modificado antes dele finalizar sua atualização, ou seja, se trata de um sistema de detecção de um fenômeno bastante conhecido em sistemas de alta concorrência, o Lost Update.

Entender o Lost Update Problem não é difícil:

A prolemática é simples, basta imaginar que 2 transações querem alterar o mesmo registro numa tabela, a segunda transação irá sobrescrever os dados da primeira, portanto descartando a atualização da primeira transação.

Dessa forma, um UPDATE é perdido quando um usuário sobrescreve o estado atual do banco de dados sem perceber que outro usuário havia alterado a mesma informação entre o momento do carregamento do registro e o momento que a atualização ocorre.

Para detectar Lost Updates, o ADF BC (ADF Business Component) se utiliza por padrão do modelo de concorrência Optimistc Locking (lock otimista). A idéia desde modelo é versionar (atribuir uma versão) as entidades de tal forma que a aplicação possa validar a versão da entidade antes de atualizar seu registro correspondente no banco; se a versão do registro a ser atualizado não confere com o registro no banco então o erro ocorre. Para implementar este vesionamento, é muito comum a entidade ter uma coluna do tipo INTEGER ou TIMESTAMP, pois ambas são facilmente incrementadas a cada UPDATE na tabela. Sua maior vantagem está na escalabilidade, pois a aplicação não precisará fazer um lock físico (Pessimistic Locking) no registro da tabela, permitindo assim que outras transações possam ler e/ou escrever no mesmo registro concorrentemente.

Este sistema de detecção de conflitos do ADF faz todo sentido em aplicações web onde temos diversos usuários enviando requisições concorrentemente para aplicação; se dois usuários tentarem modificar o mesmo registro ao mesmo tempo o erro JBO-25014 ocorre. No entanto, a forma como o ADF aplica o modelo Optimistic Locking faz com que o erro apareça mesmo quando existe somente um único usuário na aplicação.

O problema do Usuário Fantasma (Phantom User)

Embora o ADF BC evite o Lost Update de maneira automática, ele se utiliza de uma abordagem peculiar para versionar as entidades do sistema; em vez de uma coluna “Versao” do tipo INTEGER, o framework utiliza todos os campos da entidade como alternativa de versionamento, afinal de contas ele não tem como obrigar o desenvolvedor ou DBA a colocar uma coluna de versionamento na tabela. Esta abordagem simplifica a vida dos desenvolvedores, mas ela apresenta algumas fragilidades que acabam por desencadear a exceção oracle.jbo.RowInconsistentException: JBO-25014: Another user has changed the row with primary key quando menos esperamos.

Por esse motivo, é muito comum cairmos neste problema durante o desenvolvimento, onde só existe um único usuário interagindo com a aplicação, ou seja, o desenvolvedor. Neste caso, o erro pode aparecer após algumas interações numa tela de cadastro; é como se houvesse um outro usuário, um usuário fantasma, na aplicação enquanto fazemos nossos testes locais – o que não faz o menor sentido! Este problema um tanto quanto estranho é decorrente da forma como o ADF versiona suas entidades.

Como já falamos, o ADF usa todas os campos da entidade como estratégia de versionamento, desse modo, para detectar se algum outro usuário (ou transação) modificou uma entidade no banco de dados, o ADF armazena em memória (Entity Cache) os valores originais dos atributos da entidade durante seu carregamento e, no momento de atualizar o registro na tabela, o framework compara cada atributo com sua respectiva coluna no banco; se a entidade e o registro no banco não conferem (estão inconsistentes), o erro RowInconsistentException é lançado.

Perceba a fragilidade desta abordagem, todos os campos da entidade em memória devem estar consistentes com seu registro mais recente no banco, basta uma pequena inconsistência e temos o problema. Não é à toa que este erro pode ser causado comumente pelos seguintes motivos:

Triggers no banco de dados: ao enviar uma atualização pro banco uma trigger é disparada modificando algumas colunas da tabela; como o ADF BC não tem ciência destas modificações, afinal elas foram feitas dentro do SGBD, ele mantém as entidades desatualizadas em seu cache interno, o que leva ao problema exatamente no próximo commit;
Colunas com Default Value: configurar uma coluna no banco com um valor padrão (default value) pode lançar o erro pois a atualização da coluna é de responsabilidade do SGBD; cair neste cenário não é difícil, basta inserirmos uma entidade sem preencher o valor de uma coluna com default value, dessa forma o cache interno ficará desatualizado; em seguida ao tentarmos atualizar a mesma entidade o erro acontece pois o atributo não preenchido estará inconsistente com o banco;
Atributo ROWID na Entity Object: usar um atributo ROWID pode ocasionalmente desencadear o erro; apesar de incomum, algumas configurações do SGBD, como particionamento, podem modificar o valor do ROWID quando uma linha da tabela é modificada;
Select customizado na View Object: escrever um SELECT customizado no “Expert Mode” de uma View Object sem a correta sincronização ou mapeamento com os atributos da View Object; escrever uma consulta na qual preenche os atributos de uma View Object de maneira incorreta pode disparar o erro;
Atributo de domínio customizado: usar uma classe de domínio para representar um atributo da entidade sem definir corretamente seu critério de igualdade;
Múltiplos Application Modules: implementar uma funcionalidade na qual se utiliza de dois ou mais Application Modules (AM) pode acarretar o erro; basta um AM ser responsável pelo carregamento da entidade e o outro pela atualização que o problema é passível de acontecer;

A maioria das vezes estes serão os principais causadores da exceção. Contudo, outros motivos podem fazer com que o erro aconteça, por exemplo a feature Passivation/Activation do ADF, embora estes sejam mais incomuns no dia a dia.

Solução rápida para JBO-25014

Para cada situação acima há uma possível solução na qual despenderá pouco esforço para o desenvolvedor. Basta verificar em qual situação sua entidade se encontra e em seguida aplicar sua solução correspondente. Segue as soluções:

Para 1a, 2a e 3a situação basta habilitar a feature Refresh After Insert/Update do atributo da entidade que é modificado pelo SGBD, seja via trigger, defualt value ou PLSQL (a feature se encarregará de recarregar o atributo do banco após INSERT e/ou UPDATE);
Para 4a situação, verifique se o mapeamento das colunas com os atributos estão de acordo como esperado, caso contrário corrija-os;
Para 5a situação, implemente corretamente os métodos equals() e hashCode() (estes métodos são responsáveis pela identidade de um objeto);
Para 6a situação, o ideal seria carregar e atualizar a entidade dentro do mesmo AM, dessa forma ambas as operações estariam dentro da mesma transação; caso não seja possível, certifique-se de recarregar a entidade no momento apropriado;

As soluções acima funcionam como “receita de bolo” para as causas mais comuns e certamente resolverão a maioria dos casos, mas em alguns momentos talvez elas não sejam suficientes.

Solução pontual para JBO-25014: definindo o atributo versionador

Em alguns momentos não será tão fácil resolver o problema, pois talvez o atributo problemático não seja exatamente aquele que pensamos que é. Para falar a verdade, algumas vezes a inconsistência pode estar em mais de um atributo. Mas como descobrir quais deles é o causador do erro?

Na maioria das vezes o problema está em atributos do tipo data-hora como DATE ou TIMESTAMP, ou atributos com alta precisão, como DOUBLE. Mas para não ficarmos feito louco tentando adivinhar o atributo inconsistente, o ideal é tirarmos proveito dos logs do próprio ADF. Sempre que o JBO-25014 ocorre, o ADF BC imprime o log de falha indicando os atributos inconsistentes:

<EntityImpl><compare> [3359] Entity compare failed for attribute DataDeAtualizacao
<EntityImpl><compare> [3360] Original value: 2017-09-11 13:45:00.25
<EntityImpl><compare> [3361] Target value: 2017-09-11 13:45:00.48

Após identificar os atributos, o próximo passo é decidir o que fazer com relação a eles. Algumas vezes basta habilitar o Refresh After para os atributos informados no log e tem-se o problema corrigido; contudo, o problema pode ainda persistir e seja necessário ir além. Neste caso, temos duas alternativas:

Ensinar ao ADF BC como versionar determinada entidade. Para isso, basta indicar na entidade um ou mais atributos com Change Indicator; essa configuração informa ao ADF quais atributos devem ser utilizados na hora de comparar a entidade;

Para habilitar esta opção num campo, basta abrir o editor de atributos da entidade e selecionar a propriedade “Change Indicator”;
Remover o atributo que está causando o problema na comparação. Para isso, precisamos sobrescrever o método compare() da entidade e remover os atributos que não queremos que participem da comparação. O código ficaria semelhante a este:
```
@Override
protected boolean compare(SparseArray camposAComparar) {
// ignora campos que não participarão do versionamento
camposAComparar.clear(DATADEATUALIZACAO);

// invoca lógica de comparação padrão
return super.compare(camposAComparar);
}
```
É importante ficar ciente que, caso o algum campo da entidade esteja marcado como Change Indicator, somente estes campos participarão da comparação.

Perceba que a solução do Change Indicator se baseia em definir um atributo como “versionador” da entidade. Dessa forma, ao definir este atributo é importante que este seja um atributo atualizado de forma automática a cada alteração da entidade (via trigger por exemplo), isto é, este atributo não pode ser alterado pelo usuário do sistema, caso contrário cairíamos no mesmo problema.

Apesar de muitos livros informarem que é possível ter múltiplos atributos com Change Indicator, isso não acontece no jDeveloper v11.1.1.7.0, nessa versão somente um único atributo pode ser selecionado. Quando um atributo tem seu Change Indicator selecionado, o jDeveloper cuida de resetar a propriedade no outro atributo previamente marcado.

Na minha opinião, a melhor solução seria que toda tabela tivesse uma coluna VERSAO na qual denotasse a versão do registro. Para isso, o ADF nos permite definir uma History Column do tipo Version Number. Dessa forma, o próprio framework se encarrega de popular e incrementar o valor da coluna sempre que um registro é inserido ou atualizado.

Outra alternativa mais simples, seria utilizar a coluna de auditoria Modified On do ADF como versionador da entidade, já que o framework se preocupa de atualizá-la a cada alteração da entidadade.

Por fim, uma solução um tanto quanto drástica seria habilitar o recarregamento das View Objects a cada commit. O problema, é que todas as View Objects do Application Module seriam recarregadas, o que poderia levar a sérios problemas de performance caso o AM possua muitas View Objects. Na minha opinião, esta seria a alternativa menos recomendada.

Concluindo

Apesar de uma coluna do tipo History Column ser a solução mais eficiente para detectar o fenômeno Lost Update, ela com certeza não é a mais simples de aplicar em sistemas legados ou que façam integração entre sistemas via banco de dados. Por esse motivo, o ADF abre espaço para abordagens mais simples que beneficiam a produtividade do desenvolvedor e do arquiteto e que lidam com sistemas corporativos de todos os tipos e tamanhos utilizados no mercado.

Ao trabalhar com aplicações web usar Optimistic Locking é praticamente mandatório, pois assim evitamos conflitos ao atualizar registros no banco de dados e ainda garantimos uma maior escalabilidade e performance do sistema. Não é por acaso, que o lock otimista se tornou padrão no ADF desde sua versão 11.1.2.x.

Referências:

Para preparar este artigo e entender o problema de fato, eu utilizei os seguintes artigos de blogs e documentação da própria Oracle:

ADF: JBO-25014: Another user has changed the row with primary key