Controle de acesso concorrente a dados na plataforma Maximo 7.5

Este artigo descreve como a plataforma Maximo 7.5 assegura integridade de dados através de um conceito conhecido como Concorrência Otimista. Também é apresentada a utilização de logs como fonte de informações para análise de erros de acesso concorrente a dados.

Givanildo Dantas Alves, Staff Software Engineer

Givanildo Dantas AlvesGivanildo Dantas Alves

Engenheiro de Software do Laboratório de Software da IBM Brasil, com mais de cinco anos de experiência na plataforma Maximo, tanto em Asset Management como em Industry Solutions. Atua em TI desde 2004. É graduado em Ciência da Computação pela Universidade de São Paulo. Perfil My Developer Works



16/Ago/2013

Introdução

Requisitos não-funcionais assumem importância significativa (e até mesmo crucial) para a aceitação de uma aplicação mas exigem cuidados de arquitetura, design e implementação, já que podem conflitar entre si. Como exemplo, integridade de dados e desempenho: critérios estritos para garantia de integridade de dados podem afetar o desempenho, assim como otimizações para melhorar o desempenho podem abrir brechas para problemas como inconsistência de dados.

Sistemas Gerenciadores de Banco de Dados (SGBDs), com estruturas sofisticadas de armazenamento, otimização de consultas (queries) SQL e implementação de propriedades ACID (acrônimo para atomicidade, consistência, isolamento, durabilidade) tratam ambos requisitos. Para a garantia de integridade de dados em cenários com múltiplos usuários, o acesso para leitura e escrita de registros de tabelas é controlado através de bloqueios (locks), em níveis de isolamento de dados configuráveis de acordo com a necessidade: desde a ausência de isolamento, com permissão irrestrita de leitura/escrita para vários usuários ao mesmo, até o controle mais rígido, em que apenas um usuário por vez tem permissão de leitura/escrita de um determinado registro.
Quanto mais rígido o nível de isolamento, maior o número esperado de bloqueios, maior a tendência de duração de cada bloqueio por transação, portanto maior a chance de impacto negativo em desempenho, tanto pelo maior tempo de espera para liberação de acesso a registros, como pela maior probabilidade de deadlocks (dependência cíclica de recursos entre usuários).

Para aplicações em Java, a API de JDBC (Java Database Connectivity), para executar operações em bancos de dados, define quatro níveis de isolamento, para determinar a visibilidade de mudanças de dados numa transação em andamento (ou seja, antes da operação de commit) às demais transações. Em ordem de rigor:

- TRANSACTION_READ_UNCOMMITTED
- TRANSACTION_READ_COMMITTED
- TRANSACTION_REPEATABLE_READ
- TRANSACTION_SERIALIZABLE

Para mais detalhes, consulte a especificação de Java (acesse aqui).

Como forma de aliar integridade de dados a desempenho, a plataforma Maximo aplica um mecanismo conhecido como Concorrência Otimista, que tende a minimizar a duração de bloqueios.


Concorrência Otimista x Concorrência Pessimista

Segundo o mecanismo de Concorrência Otimista, todo registro deve ter alguma informação que indique sua versão atual, de forma que qualquer alteração do registro deve ser acompanhada da atribuição de uma nova versão ao registro. Tal versão pode ser uma coluna extra numa tabela ou mesmo um conjunto de colunas existentes, desde que versões não coincidam entre si. Como exemplo simples, o indicador de versão pode ser baseado numa coluna de tipo numérico com alocação razoável de bits (para permitir grande variabilidade de valores), com incremento de valor da versão para cada alteração do registro correspondente.

Já que um registro lido do banco de dados traz consigo sua versão, pode-se comparar tal versão com a versão presente no banco de dados no momento de persistir mudanças no registro. Um valor diferente no banco de dados indica que outra transação alterou o mesmo registro, portanto o que havia sido lido deixou de representar o estado atual do registro no banco, e prosseguir com a alteração poderia causar inconsistência de dados - perda de informação neste caso.

Aumento de desempenho é a principal vantagem da Concorrência Otimista. Como a validação de versão de um registro só é feita no momento de persistir mudanças no banco, vários usuários podem ler o mesmo registro. E menos bloqueios implicam em menor custo de gerenciamento de integridade de dados.
Por outro lado, em termos de usabilidade, há desvantagens para cenários de alteração simultânea dos mesmos registros. Um usuário pode se deparar com repetidas mensagens de erro até conseguir finalizar sua operação com sucesso.

Já o mecanismo de Concorrência Pessimista é mais conservador: consiste em bloquear um registro no momento em que é lido do banco de dados e liberar o bloqueio somente ao fim da transação.


Concorrência Otimista na plataforma Maximo 7.5

Na plataforma Maximo, o indicador de versão é representado pela coluna ROWSTAMP, presente em todas as tabelas, e armazena a data da última modificação do registro correspondente. A versão é automaticamente atribuída ao registro a partir de triggers.

A operação verificação de versão + atualização do registro é atômica: o comando SQL para atualização do registro possui um filtro na cláusula WHERE para verificar a versão. Como o comando UPDATE devolve o número de registros atualizados, zero como valor devolvido é indicador de que outra uma transação concorrente alterou o registro.

Como exemplo, um fluxo básico de atualização de um Ativo:

1. Usuário abre um Ativo na aplicação de Gerenciamento de Ativos. Registro correspondente é lido do banco de dados, a partir de uma consulta conforme o modelo abaixo:

SELECT * from ASSET where <CLÁUSULA>

2. ROWSTAMP do registro, também trazido como resultado da consulta, é armazenado em memória

3. Atributos do Ativo são exibidos no browser, nos campos correspondentes

4. Usuário altera valores de alguns campos

5. Usuário clica no ícone para persistir as alterações. Operação executada no banco de dados:

UPDATE ASSET SET COL1 = <VAL1>, COL2 = <VAL2>, ….WHERE … AND ROWSTAMP = <VERSÃO>

6. Se a operação for bem sucedida, uma nova versão é atribuída ao registro

Caso dois usuários tentem atualizar o mesmo Ativo ao mesmo tempo, aquele que tentar persistir as mudanças por último receberá o erro BMXAA8229W - O registro ASSET : Site=BEDFORD Ativo=11250 foi atualizado por outro usuário. Suas alterações não foram salvas. Atualize o registro e tente novamente. e deverá reiniciar a transação - ou seja, reabrir o Ativo na aplicação, efetuar novamente as alterações e persisti-las.


Análise de erros a partir de logs

Somente o que é exibido na mensagem BMXAA8229W pode não ser suficiente para análise de uma determinada ocorrência de erro envolvendo acesso concorrente a dados. Para atender à necessidade de mais informações, a plataforma Maximo oferece uma configuração para registro de mais detalhes em logs.
Para habilitar tal configuração, siga os seguintes passos:

1. No menu no canto superior direito, selecione Ir Para -> Configuração do Sistema ->Configuração de Plataforma -> Criação de Log

Clique aqui para ver a figura ampliada

2. Na seção Criadores de Log Principais, busque pelo registro com a chave log4j.logger.maximo.sql

3. Para o registro encontrado, modifique o Nível de Log para INFO

Clique aqui para ver a figura ampliada

4. Clique no ícone para salvar as alterações

5. Será exibido um alerta. Clique OK

6. No menu Selecionar Ação, clique em Aplicar Configurações

Clique aqui para ver a figura ampliada

A partir de agora, mais informações sobre transações SQL executadas, incluindo erros de acesso concorrente a dados, serão registradas em logs. Os logs podem ser enviados para arquivos ou para a própria saída padrão (stdout) do servidor de aplicação. Para mais detalhes, consulte a documentação da plataforma Maximo (acesse aqui).


Exemplo

Abaixo, trechos de logs de um erro de acesso concorrente a dados para atualização de um Ativo:

[12/27/12 22:56:20:424 BRST] 0000004f SystemOut 	O 27 Dec 2012 22:56:20:424 [INFO]
[MXServerc1] [] BMXAA6719I - USER = (WILSON) SPID = (9.6.127.89.61024.121227003507) app 
(ASSET) object (ASSET) : update asset set changeby=?,pluscduedate=?,description=?,
changedate=? where assetuid=? and rowstamp=?

[12/27/12 22:56:20:424 BRST] 0000004f SystemOut 	O 27 Dec 2012 22:56:20:424 [INFO]
[MXServerc1] [] BMXAA6721I - Bind value for CHANGEBY = WILSON

[12/27/12 22:56:20:424 BRST] 0000004f SystemOut 	O 27 Dec 2012 22:56:20:424 [INFO]
[MXServerc1] [] BMXAA6721I - Bind value for PLUSCDUEDATE = null

[12/27/12 22:56:20:424 BRST] 0000004f SystemOut 	O 27 Dec 2012 22:56:20:424 [INFO]
[MXServerc1] [] BMXAA6721I - Bind value for DESCRIPTION = Circulation Fan- Centrifugal/ 
20/000 CFM232

[12/27/12 22:56:20:424 BRST] 0000004f SystemOut 	O 27 Dec 2012 22:56:20:424 [INFO]
[MXServerc1] [] BMXAA6721I - Bind value for CHANGEDATE = 2012-12-26 22:54:35.095

[12/27/12 22:56:20:424 BRST] 0000004f SystemOut 	O 27 Dec 2012 22:56:20:424 [INFO] 
[MXServerc1] [] BMXAA6721I - Bind value for ASSETUID = 40

[12/27/12 22:56:20:424 BRST] 0000004f SystemOut 	O 27 Dec 2012 22:56:20:424 [INFO] 
[MXServerc1] [] BMXAA6721I - Bind value for rowstamp = 7139225

[12/27/12 22:56:20:424 BRST] 0000004f SystemOut 	O 27 Dec 2012 22:56:20:424 [ERROR]
[MXServerc1] [] BMXAA8229W - Record ASSET :  Site=BEDFORD Ativo=11250 has been updated
by another user. Your changes have not been saved. Refresh the record and try again.
psdi.util.MXRowUpdateException: BMXAA8229W - Record ASSET :  Site=BEDFORD Ativo=11250
has been updated by another user. Your changes have not been saved. Refresh the record
and try again.

O erro ocorreu na execução do comando SQL para atualizar Ativo 11250. Pelo controle de Concorrência Otimista da plataforma Maximo, o Ativo foi atualizado por uma transação concorrente.
Pelo número da versão do registro (7139225, valor atribuído à coluna TIMESTAMP), pode-se por exemplo fazer uma busca nos logs por detalhes da transação concorrente em que o mesmo registro foi atualizado, instantes antes do erro:

  [12/27/12 22:56:16:321 BRST] 0000004f SystemOut 	O 27 Dec 2012 22:56:16:321 [INFO]
  [MXServerc1] [] BMXAA6719I - USER = (WILSON) SPID = (9.6.127.89.61024.121227003507) app 
  (ASSET) object (ASSET) : update asset set changeby=?,pluscduedate=?,description=?,
  changedate=? where assetuid=? and rowstamp=?
  
  [12/27/12 22:56:16:321 BRST] 0000004f SystemOut 	O 27 Dec 2012 22:56:16:321 [INFO]
  [MXServerc1] [] BMXAA6721I - Bind value for CHANGEBY = WILSON
  
  [12/27/12 22:56:16:321 BRST] 0000004f SystemOut 	O 27 Dec 2012 22:56:16:321 [INFO]
  [MXServerc1] [] BMXAA6721I - Bind value for PLUSCDUEDATE = null
  
  [12/27/12 22:56:16:321 BRST] 0000004f SystemOut 	O 27 Dec 2012 22:56:16:321 [INFO]
  [MXServerc1] [] BMXAA6721I - Bind value for DESCRIPTION = Circulation Fan- Centrifugal/
  20/000 CFM232
  
  [12/27/12 22:56:16:321 BRST] 0000004f SystemOut 	O 27 Dec 2012 22:56:16:321 [INFO]
  [MXServerc1] [] BMXAA6721I - Bind value for CHANGEDATE = 2012-12-26 22:54:30.977
  
  [12/27/12 22:56:16:321 BRST] 0000004f SystemOut 	O 27 Dec 2012 22:56:16:321 [INFO]
  [MXServerc1] [] BMXAA6721I - Bind value for ASSETUID = 40
  
  [12/27/12 22:56:16:321 BRST] 0000004f SystemOut 	O 27 Dec 2012 22:56:16:321 [INFO] 
  [MXServerc1] [] BMXAA6721I - Bind value for rowstamp = 7139225

Conclusão

Através da aplicação do mecanismo de Concorrência Otimistista, a plataforma Maximo assegura integridade de dados sem desconsiderar desempenho.
Os conceitos abordados neste artigo são relevantes para desenvolvimento e manutenção de aplicações como para administração de sistemas em produção.


Referências

Documentação de IBM Maximo Asset Management 7.5

Java 6 API Specification

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tivoli
ArticleID=940780
ArticleTitle=Controle de acesso concorrente a dados na plataforma Maximo 7.5
publish-date=08162013