Minimizando o impasse da mesa no meu cenário com o Oracle e Innodb

Question

Eu tenho 35 funções que atualizam 1 a 3 tabelas, em uma transação. No entanto, eles não apenas executam atualizações, mas também fazem consultas.

• A Tabela 1 atualiza apenas ações e algumas consultas.
• A Tabela 2 faz consultas e atualizações de nível de linha nas linhas existentes e, às vezes, exclui e adiciona linhas. A Tabela 2 pode ter consultas dentro da transação antes e após as deleções e inserções da linha e ou atualizações.
• A Tabela 3 faz atualizações de linha com base nos resultados das ações da Tabela 2 acima.

Minha primeira ação será garantir que as atualizações da Tabela 3 sejam feitas no final.

A Tabela 1 é independente das outras 2 tabelas e provavelmente pode ser a primeira ou a última. Portanto, a Tabela 2 deve vir antes da Tabela 3 alterações.

Minha primeira preocupação é que, com as ações da Tabela 2, faça consultas, atualizo e depois mais consultas e mais atualizações às vezes. Eu tenho que reorganizar meu código para não fazer isso.

Minha segunda preocupação é que a Tabela 3 é a tabela de que, com os threads do servlet, deve ser rápido. A Tabela 3 é usada para simplesmente consultas por si só. Mas parece que os bloqueios no nível da linha interromperão essas consultas.

Se for necessário, posso colocar o código de manutenção do conjunto de tabela descrito acima em um único processo em todo o cluster, a partir de um thread. A velocidade das atualizações não importa. Apenas que as consultas contra a Tabela 3 são rápidas. E que nunca há nenhum impasse.

Não conheço diferenças entre Oracle e Innodb, então tenho perguntas lá. (Pretendo atualizar para o Oracle mais tarde.)

Basicamente, estou procurando dicas sobre o que observar. Obviamente, eu poderia forçar um bloqueio de mesa completo na Tabela 2 e, em seguida, a Tabela 3 no início de cada função de atualizador, mas o thread da consulta da tabela 3 Servlet sofria. Então isso não parece uma solução.

Além disso, estou preocupado com apenas em relação à Tabela 2, que algumas funções fazem consultas, atualizações com base na consulta, novas consultas com base na atualização e depois mais atualizações, incluindo resultados fluentes para atualizações para a Tabela 3. Isso parece realmente desagradável.

Recomendações? Andy

Pode haver atualizações simultâneas nas mesmas linhas de 2 tabelas, e eu tomei o cuidado de acertar as tabelas com as atualizações na mesma ordem. Uma das tabelas tem 2 índices e parece que é necessária uma trava de mesa para atualizar o índice? Algumas das funções consulta Tabela 1, atualize a Tabela 1 e, em seguida, opcionalmente, consulte a Tabela 2 e atualize a Tabela 2, em um loop de repetição. Esta tabela contém todos os relacionamentos com filhos pais em uma árvore de todo o meu conteúdo, por isso é uma atualização de alto volume em todos os usuários.

Answer 1

Em primeiro lugar, as consultas no Oracle (e acredito que o InnoDB) não pegam uma fechadura, a menos que você use para atualizar.

Em segundo lugar, não tenho idéia da sua escala de aplicativo. Quantas transações simultâneas você espera ter? Você espera que eles estejam atualizando as mesmas linhas?

O tipo de aplicação que pode sofrer de impasse é um sistema de reservas ou bilhetes (por exemplo, pessoas que tentam reservar os mesmos assentos em um teatro), especialmente em situações de alta concorrência (o novo programa fica disponível para reserva).

Se você se encaixar nesse perfil, provavelmente deseja antecipar situações de impasse. No entanto, eu considerava pelo menos simplesmente prender o erro, reverter e depois realizar a transação. Se você entrar em mais detalhes em suas estruturas de mesa, relacionamentos e critérios de atualização, um ponto apropriado para o bloqueio poderá se tornar aparente.