Em 30 de janeiro de 2014 10:02, Anderson Marques
jackvalant...@gmail.com escreveu:
Bom dia, pessoal estamos desenvolvendo um sistema de gerenciamento de
estoque, porem surgiu essa duvidaa procedure pode travar o sistema
dependendo da demanda de requisição simultânea, tipo umas 1500 requisições
simultâneas?
1500 requisições simultâneas (a.k.a ao mesmo tempo) é algo realmente
grande. Cada requisição irá consumir 1 núcleo de CPU, logo haverá
distribuição entre os cores existentes, criando uma fila. Isso não
implica em travar, exceto se a sua procedure concorrer pelos mesmos
registros de uma tabela. Leia sobre níveis de isolamento (ou isolação,
como alguns dizem) [1] para ter uma idéia do que pode ocorrer.
o problema que estamos resolvendo com a procedure é a movimentação do
estoque
, na entrada e saída, fizemos uma simulação onde dois usuários trabalham no
mesmo item fazendo a saida, do modo que está implementado apenas no código
ambos trabalharam o mesmo valor de estoque só que o estoque para o 2ª ja não
era o mesmo.
a procedure é a melhor implementação para resolver isso?
Levando em consideração a aquisição de LOCK corretamente - usando os
conceitos de [1] - você poderá tratar isso diretamente na aplicação
sem criar objetos de banco. Exceto se existir algum outro agente além
do seu aplicativo que altere valores que impliquem na modificação de
saldos eu vejo que através de um trigger e uma procedure você obterá
resultados mais satisfatórios, porém há de se preocupar com os limites
da regra de negócio - para não misturar metade no programa ou metade
no banco de dados.
O que você precisa é alterar o isolamento da transação no momento de
alterar o registro com saldo com [2] [3]:
1) Selecionar o registro a ser alterado com SELECT ... FOR UPDATE;
2) Alterar o registro pela procedure chamada por trigger, ou, pelo programa;
3) COMMIT na transação pela aplicação;
Quando 2 transações tentarem selecionar o mesmo registro pelo SELECT
... FOR UPDATE, a primeira que tiver acesso ao registro irá conseguir.
Enquanto essa primeira transação não for encerrada (COMMIT ou
ROLLBACK), qualquer outra transação que executar o SELECT ... FOR
UPDATE sobre o mesmo registro (ou vários, incluindo o registro que já
está resevado) irá ficar em LOCK WAIT.
Outra opção é alterar o nível de isolamento e usando cursores dentro
de uma procedure para não precisará usar o SELECT ... FOR UPDATE.
[1] http://www.postgresql.org/docs/9.3/static/transaction-iso.html
[2] http://www.postgresql.org/docs/9.3/static/sql-set-transaction.html
[3] http://www.postgresql.org/docs/9.3/static/explicit-locking.html
TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
