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 duvida....a 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
